Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group