Re: [HACKERS] Optimizer cleanup to avoid redundant work on joins
| От | Tom Lane |
|---|---|
| Тема | Re: [HACKERS] Optimizer cleanup to avoid redundant work on joins |
| Дата | |
| Msg-id | 7150.949878864@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: [HACKERS] Optimizer cleanup to avoid redundant work on joins (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: [HACKERS] Optimizer cleanup to avoid redundant work on joins
|
| Список | pgsql-hackers |
> Anyway, in the current sources things are certainly broken, and I don't
> see any real alternative except to press forward with moving join
> restrictinfos into JoinPaths. Even if we figure out exactly why 6.5.*
> is somehow failing to fail,
Er ... um ... ahem ... DUH! The reason 6.5.3 works is that it does in
fact keep join restrictinfo pointers in JoinPaths. I had eliminated
those pointers (the thoroughly undocumented "pathinfo" field) because
I thought that the lists were always the same as the parent relations'
restrictinfo lists. Which they were --- at the time of creation of a
JoinPath. What I missed was that prune.c moved a joinpath to belong
to a different RelOptInfo with (potentially) a different restrictinfo
list, but the joinpath needs to keep its original restrictinfo list.
In other words, I broke it.
Since surgery needs to be done anyway, I'm inclined to press ahead
with the changes I was going to put off. On the other hand, if the
patient had a vote, it might ask for a second opinion ;-)
regards, tom lane
В списке pgsql-hackers по дате отправления: