Re: Redundant bitmap index scans on smallint column

Поиск
Список
Период
Сортировка
От Marti Raudsepp
Тема Re: Redundant bitmap index scans on smallint column
Дата
Msg-id CABRT9RA+MiebZfoBj3A7Wm1HQTdajeLTzJYvsAGsMudtEEkJqQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Redundant bitmap index scans on smallint column  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Tue, Sep 6, 2011 at 19:51, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Marti Raudsepp <marti@juffo.org> writes:
>> So it seems the more fundamental issue is that b=0 and b='0'
>> conditions are normalized differently when b is smallint.
>
> That's not a "fundamental issue", if by that you mean that it's a bug to
> be fixed.

That was a bad choice of words, I meant "fundamental reason".

> I realized that that patch is no good because it will break estimation
> for inner-indexscan cases, where the selectivity of a bitmap index might
> legitimately be better than what you'd get from the restriction clauses
> alone.  Possibly we could adapt the idea to use in choose_bitmap_and,
> but it'll take more thought.

Anyway the conditions for triggering this kind of plan are rather
obscure, so unless there is a simple solution, it's probably not worth
fixing.

You need a constant query WHERE expression and partial index that
mixes b=0 and b='0' syntax, on a non-integer column. The workaround is
also straightforward: be consistent how you write the expression.

The planner will only choose such a plan when you have a fairly large
heap and small indexes, so the heap scan is likely to dominate query
time anyway. In the original query it was a matter of 66 ms (single
bitmap scan) vs 82 ms (redundant bitmap scans)

Regards,
Marti


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: timezone GUC
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Large C files