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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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