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 по дате отправления: