Re: [HACKERS] propose to pushdown qual into EXCEPT

2016-12-26 Thread Tom Lane
I wrote: > tl;dr: I now think what the patch proposes to do is legit. There's a heck > of a lot of work to be done on the comments it's falsified, though. Hmm, wait a minute. I mentioned before that what nodeSetOp.c actually returns is N copies of the same representative tuple. That in itself

Re: [HACKERS] propose to pushdown qual into EXCEPT

2016-12-23 Thread Tom Lane
Alvaro Herrera writes: > Tom Lane wrote: >> That is not an adequate argument for such a change being okay. Postgres, >> with its extensible set of datatypes, has to be much more careful about >> the semantic soundness of optimizations than some other DBs do. > Can we

Re: [HACKERS] propose to pushdown qual into EXCEPT

2016-12-23 Thread Alvaro Herrera
Tom Lane wrote: > "=?ISO-8859-1?B?QXJtb3I=?=" writes: > > Because PG does not pushdown qual to the none of the subquery. And I > > check the source code, find some comments in > > src/backend/optimizer/path/allpaths.c, which says "If the subquery > > contains EXCEPT

Re: [HACKERS] propose to pushdown qual into EXCEPT

2016-12-23 Thread Tom Lane
"=?ISO-8859-1?B?QXJtb3I=?=" writes: > Because PG does not pushdown qual to the none of the subquery. And I > check the source code, find some comments in > src/backend/optimizer/path/allpaths.c, which says "If the subquery > contains EXCEPT or EXCEPT ALL set ops we

[HACKERS] propose to pushdown qual into EXCEPT

2016-12-23 Thread Armor
Recently, we find PG fails to generate an effective plan for following SQL: select * from (select * from table1 execpt select * from table2) as foo where foo.a > 0; Because PG does not pushdown qual to the none of the subquery. And I check the source code, find some comments in