I wrote:
> Andrew Gierth writes:
>> "Bruce" == Bruce Momjian writes:
>> Bruce> Uh, did this ever get addressed?
>> It did not.
> It dropped off the radar screen (I think I'd assumed the patch would
> appear in the next commitfest, which it didn't unless I missed something).
> I'll make a note t
Andrew Gierth writes:
> "Bruce" == Bruce Momjian writes:
> Bruce> Uh, did this ever get addressed?
> It did not.
It dropped off the radar screen (I think I'd assumed the patch would
appear in the next commitfest, which it didn't unless I missed something).
I'll make a note to look at it once
> "Bruce" == Bruce Momjian writes:
Bruce> Uh, did this ever get addressed?
It did not.
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Uh, did this ever get addressed?
---
On Sun, Jul 6, 2014 at 08:56:00PM +0100, Andrew Gierth wrote:
> > "Tom" == Tom Lane writes:
>
> >> I've experimented with the attached patch, which detects when this
> >> situati
> "Tom" == Tom Lane 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 t
Andrew Gierth writes:
> commit 807a40c5 fixed a bug in handling of (new in 9.2) functionality
> of ScalarArrayOpExpr in btree index quals, forcing the results of
> scans including such a qual to be treated as unordered (because the
> order can in fact be wrong).
> However, this kills any chance of
Spent some time analyzing a severe performance regression on 9.1->9.3
upgrade for a user on IRC. Narrowed it down to this:
commit 807a40c5 fixed a bug in handling of (new in 9.2) functionality
of ScalarArrayOpExpr in btree index quals, forcing the results of
scans including such a qual to be treat
