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
d
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 use the record_image_ops mec
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 or EXCEPT ALL set op
"=?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 cannot push quals int
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 src/backen