Re: Bitmap index scans use of filters on available columns

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Bitmap index scans use of filters on available columns
Дата
Msg-id 16141.1446676357@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Bitmap index scans use of filters on available columns  (Jeff Janes <jeff.janes@gmail.com>)
Ответы Re: Bitmap index scans use of filters on available columns
Список pgsql-hackers
Jeff Janes <jeff.janes@gmail.com> writes:
> On Wed, Nov 4, 2015 at 7:14 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> You're missing my point: that is possible in an indexscan, but *not* in a
>> bitmap indexscan, because the index AM APIs are totally different in the
>> two cases.  In a bitmap scan, nothing more than a TID bitmap is ever
>> returned out to anyplace that could execute arbitrary expressions.

> I had thought it must already be able to execute arbitrary
> expressions, due to the ability to already support user-defined btree
> ops (and ops of non-btree types in the case of other index types).

No.  An index AM is only expected to be able to evaluate clauses of
the form <indexed_column> <indexable_operator> <constant>, and the key
restriction there is that the operator is one that the AM has volunteered
to support.  Well, actually, it's the opclass more than the AM that
determines this, but anyway it's not just some random operator; more than
likely, the AM and/or opclass has got special logic about the operator.

This also ties into Robert's point about evaluation of operators against
index entries for dead or invisible rows.  Indexable operators are much
less likely than others to have unexpected side-effects.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: Request: pg_cancel_backend variant that handles 'idle in transaction' sessions
Следующее
От: Vik Fearing
Дата:
Сообщение: Re: Request: pg_cancel_backend variant that handles 'idle in transaction' sessions