On Oct16, 2011, at 20:26 , Tom Lane wrote:
Florian Pflug f...@phlo.org writes:
On Oct16, 2011, at 19:09 , Tom Lane wrote:
That doesn't seem like the same thing at all, because the indexed column
is on different sides of the expression in the two cases. The situation
that I'm worried about is
Noah Misch n...@leadboat.com writes:
On Sat, Oct 15, 2011 at 02:58:45PM -0400, Tom Lane wrote:
[algorithm for a regular index scan satisfying key IN (...)]
Sounds sensible. The algorithm applies to more than ScalarArrayOpExpr; is it
not the ability to handle an OR'ed list of ScanKey instead
Florian Pflug f...@phlo.org writes:
On Oct15, 2011, at 20:58 , Tom Lane wrote:
So, at least as far as btrees are concerned, it seems like I implemented
the ScalarArrayOpExpr logic at the wrong level and it ought to be pushed
down into the index AM. The above rules seem pretty btree-specific,
On Oct16, 2011, at 19:09 , Tom Lane wrote:
Florian Pflug f...@phlo.org writes:
On Oct15, 2011, at 20:58 , Tom Lane wrote:
So, at least as far as btrees are concerned, it seems like I implemented
the ScalarArrayOpExpr logic at the wrong level and it ought to be pushed
down into the index AM.
Florian Pflug f...@phlo.org writes:
On Oct16, 2011, at 19:09 , Tom Lane wrote:
That doesn't seem like the same thing at all, because the indexed column
is on different sides of the expression in the two cases. The situation
that I'm worried about is indexedcolumn op ANY(arrayconstant), and
On Sat, Oct 15, 2011 at 2:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
In principle somebody could be doing something like
WHERE pointcol @ ANY (ARRAY[list of box values])
and expecting that to generate a bitmap indexscan on a GIST index, but
is it likely that anyone is doing that? (As
On Sat, Oct 15, 2011 at 02:58:45PM -0400, Tom Lane wrote:
[algorithm for a regular index scan satisfying key IN (...)]
So, at least as far as btrees are concerned, it seems like I implemented
the ScalarArrayOpExpr logic at the wrong level and it ought to be pushed
down into the index AM. The
