Jeff Janes <jeff.ja...@gmail.com> writes:
> Bisects down to:
> 606c0123d627b37d5ac3f7c2c97cd715dde7842f is the first bad commit
> commit 606c0123d627b37d5ac3f7c2c97cd715dde7842f
> Author: Simon Riggs <si...@2ndquadrant.com>
> Date: Tue Nov 18 10:24:55 2014 +0000
> Reduce btree scan overhead for < and > strategies
On looking at this, the problem seems pretty obvious: that commit simply
fails to consider multi-column keys at all. (For that matter, it also
fails to consider zero-column keys.) I think the logic might be all right
if a test on so->numberOfKeys == 1 were added; I don't see how the
optimization could work in multi-column cases.
However, I'm not sure that's 100% of the issue, because in playing around
with this I was having a harder time reproducing the failure outside of
Tobias' example than I expected. There may be more than one bug, or there
may be other changes that sometimes mask the problem.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
