Re: Extra cost of "lossy mode" Bitmap Scan plan - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Extra cost of "lossy mode" Bitmap Scan plan
Date
Msg-id 4136ffa0904280051i413c26e3ledb626cd5598b79a@mail.gmail.com
Whole thread Raw
In response to Re: Extra cost of "lossy mode" Bitmap Scan plan  (higepon <higepon@gmail.com>)
Responses 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>)
List 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 by date:

Previous
From: higepon
Date:
Subject: Re: Extra cost of "lossy mode" Bitmap Scan plan
Next
From: Sam Halliday
Date:
Subject: Re: RFE: Transparent encryption on all fields