Re: Extra cost of "lossy mode" Bitmap Scan plan

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: Extra cost of "lossy mode" Bitmap Scan plan
Дата
Msg-id 4136ffa0904280051i413c26e3ledb626cd5598b79a@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Extra cost of "lossy mode" Bitmap Scan plan  (higepon <higepon@gmail.com>)
Ответы Re: Extra cost of "lossy mode" Bitmap Scan plan  (higepon <higepon@gmail.com>)
Re: Extra cost of "lossy mode" Bitmap Scan plan  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Tue, Apr 28, 2009 at 7:45 AM, higepon <higepon@gmail.com> wrote:
> "How much extra cost should we add for lossy mode?".

There is something odd in this concern. Normally people aren't raising
and lowering their work_mem so the comparison would be between a plan
where the planner expects to see n records and a plan where the
planner expects to see n+1 records where n would fit and n+1 wouldn't.

It seems like an awfully narrow corner case where n records would be
faster as a bitmap index scan but n+1 records would be faster as an
index scan because the bitmap becomes lossy. The whole point of bitmap
scans is that they're faster for large scans than index scans.

If the logic you're suggesting would kick in at all it would be for a
narrow range of scan sizes, so the net effect would be to use an index
scan for small scans, then switch to a bitmap scan, then switch back
to an index scan when the bitmap scan becomes lossy, then switch back
to a lossy bitmap scan for large scans. I'm thinking that even if it's
slightly faster when the planner has perfect inputs the downsides of
switching back and forth might not be worth it. Especially when you
consider than the planner is often going on approximate estimates and
it is probably not switching in precisely the right spot.

-- 
greg


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

Предыдущее
От: higepon
Дата:
Сообщение: Re: Extra cost of "lossy mode" Bitmap Scan plan
Следующее
От: Sam Halliday
Дата:
Сообщение: Re: RFE: Transparent encryption on all fields