Re: Allowing join removals for more join types
От | Tom Lane |
---|---|
Тема | Re: Allowing join removals for more join types |
Дата | |
Msg-id | 6351.1404663344@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Allowing join removals for more join types (David Rowley <dgrowley@gmail.com>) |
Ответы |
Re: Allowing join removals for more join types
|
Список | pgsql-hackers |
David Rowley <dgrowley@gmail.com> writes: > On 6 July 2014 03:20, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Just to note that I've started looking at this, and I've detected a rather >> significant omission: there's no check that the join operator has anything >> to do with the subquery's grouping operator. > hmm, good point. If I understand this correctly we can just ensure that the > same operator is used for both the grouping and the join condition. Well, that's sort of the zero-order solution, but it doesn't work if the join operators are cross-type. I poked around to see if we didn't have some code already for that, and soon found that not only do we have such code (equality_ops_are_compatible) but actually almost this entire patch duplicates logic that already exists in optimizer/util/pathnode.c, to wit create_unique_path's subroutines query_is_distinct_for et al. So I'm thinking what this needs to turn into is an exercise in refactoring to allow that logic to be used for both purposes. I notice that create_unique_path is not paying attention to the question of whether the subselect's tlist contains SRFs or volatile functions. It's possible that that's a pre-existing bug. regards, tom lane
В списке pgsql-hackers по дате отправления: