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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Greg Stark <stark(at)enterprisedb(dot)com>, higepon <higepon(at)gmail(dot)com>, Itagaki Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Extra cost of "lossy mode" Bitmap Scan plan
Date: 2009-04-28 14:34:18
Message-ID: 2679.1240929258@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Apr 28, 2009 at 3:51 AM, Greg Stark <stark(at)enterprisedb(dot)com> wrote:
>> If the logic you're suggesting would kick in at all it would be for a
>> narrow range of scan sizes,

> You may be right, but on the other hand, I'm not sure there's any
> sense in NOT trying to model the impact of the additional heap
> fetches.

I think it's probably useless. In the first place, at reasonable values
of work_mem the effect is going to be negligible (in the sense that a
plain indexscan would never win). In the second place, there isn't any
way to guess the extent of lossiness at plan time --- it depends on how
much the target rows are "clumped" on particular pages. The planner
hasn't got any stats that would let it guess that, and even if we tried
to collect such stats they'd probably be too unstable to be useful.

There are boatloads of effects that the planner doesn't model. This
one seems very far down the list of what we should worry about.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2009-04-28 14:36:14 Re: Extra cost of "lossy mode" Bitmap Scan plan
Previous Message Tom Lane 2009-04-28 14:16:31 Re: Clean shutdown and warm standby