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
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 |