Re: Performance regression: 9.2+ vs. ScalarArrayOpExpr vs. ORDER BY

>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

>> I've experimented with the attached patch, which detects when this
>> situation might have occurred and does another pass to try and
>> build ordered scans without the SAOP condition. However, the
>> results may not be quite ideal, because at least in some test
>> queries (not all) the scan with the SAOP included in the
>> indexquals is being costed higher than the same scan with the SAOP
>> moved to a Filter, which seems unreasonable.

Tom> I'm not convinced that that's a-priori unreasonable, since the
Tom> SAOP will result in multiple index scans under the hood.
Tom> Conceivably we ought to try the path with and with SAOPs all the
Tom> time.

OK, here's a patch that always retries on lower SAOP clauses, assuming
that a SAOP in the first column is always applicable - or is even that
assumption too strong?

--
Andrew (irc:RhodiumToad)