Re: [HACKERS] Arrays broken on temp tables
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] Arrays broken on temp tables |
Дата | |
Msg-id | 199911110237.VAA08435@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Arrays broken on temp tables (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Arrays broken on temp tables
|
Список | pgsql-hackers |
> The problem is that the rangetable code doesn't realize that the logical > and physical names refer to the same table, so when the > subscript-processing code generates a reference to > <physicaltablename>.<attribute> the parser generates a second RTE for > the physical table name, in addition to the already-existing RTE for the > logical table name. This causes the planner to generate a join, because > it can see no difference between this situation and > FROM tablename, tablename aliasname > which *should* cause a join. But the join causes each tuple to be > processed multiple times, which is the wrong thing for this case. > > There is more than one way we could attack this, but I think the > cleanest answer will be to make it possible to extract a logical > table name from a relcache entry. Well, as I remember, the good news is that our code was fine, and the original poster just missed the WHERE clause on the update. So I guess that gets us off the hook for a while. However, now looking at the posting again: http://www.postgresql.org/mhonarc/pgsql-hackers/1999-11/msg00213.html I am confused again. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
В списке pgsql-hackers по дате отправления: