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

Re: Choosing between seqscan and bitmap scan

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>
Cc: Teodor Sigaev <teodor(at)sigaev(dot)ru>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Choosing between seqscan and bitmap scan
Date: 2010-04-29 14:10:36
Message-ID: 10945.1272550236@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Oleg Bartunov <oleg(at)sai(dot)msu(dot)su> writes:
> On Thu, 29 Apr 2010, Tom Lane wrote:
>> There's a fuzz factor of (IIRC) 1% in path cost comparisons.  It's
>> deciding that the seqscan and bitmapscan total costs are not
>> meaningfully different; then since the startup costs *are* meaningfully
>> different, it's making the choice on the basis of cheaper startup cost.

> hmm, what if we add index scan preference inside 1% tolerance ?

Why?  IMO this behavior is perfectly reasonable; in fact I've sometimes
thought the fuzz threshold should be a lot more than 1%.  There is no
reason for the planner to believe that the bitmapscan is meaningfully
superior on total cost, while it is clearly inferior on startup cost.

If your problem is that the seqscan is a lot slower in reality,
the answer to that is to twiddle the cost parameters so that the
planner knows that, not to object to this logic.

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2010-04-29 14:17:22
Subject: Re: Toast rel options
Previous:From: Oleg BartunovDate: 2010-04-29 14:02:41
Subject: Re: Choosing between seqscan and bitmap scan

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