On Oct16, 2011, at 20:26 , Tom Lane wrote:
> Florian Pflug 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 "
Florian Pflug 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
>> what
On Oct16, 2011, at 19:09 , Tom Lane wrote:
> Florian Pflug 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. Th
Florian Pflug 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, so
>> I
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, so
> I don't think that we ought to
Noah Misch 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 of an AND'e
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.
On Sat, Oct 15, 2011 at 2:58 PM, Tom Lane 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 opposed to the e
Almost immediately after we committed index-only scans, there were
complaints that it didn't work with "indexkey IN (...)" conditions, that
is ScalarArrayOpExpr index quals. That's because the current code only
supports ScalarArrayOpExpr as a bitmap indexscan qual, not a regular
indexscan. The ex
