Re: BETWEEN optimizer problems with single-value - Mailing list pgsql-performance

From Simon Riggs
Subject Re: BETWEEN optimizer problems with single-value
Date
Msg-id 1142468678.3859.221.camel@localhost.localdomain
Whole thread Raw
In response to Re: BETWEEN optimizer problems with single-value  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: BETWEEN optimizer problems with single-value  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-performance
On Thu, 2006-03-16 at 00:07 +0000, Simon Riggs wrote:
> On Wed, 2006-03-15 at 14:17 -0500, Tom Lane wrote:
>
> > It looks to me like this is a matter of bad cost estimation, ie, it's
> > thinking the other index is cheaper to use.  Why that is is not clear.
> > Can we see the pg_stats rows for ctofcNo and calDate?
>
> ISTM that when the BETWEEN constants match we end up in this part of
> clauselist_selectivity()...

(and now for the whole email...)

    /*
     * It's just roundoff error; use a small positive
     * value
     */
    s2 = 1.0e-10;

so that the planner underestimates the cost of using "Cal_CalDate" so
that it ends up the same as "Cal_CtofcNo", and then we pick
"Cal_CalDate" because it was created first.

Using 1.0e-10 isn't very useful... the selectivity for a range should
never be less than the selectivity for an equality, so we should simply
put in a test against one of the pseudo constants and use that as the
minimal value. That should lead to raising the apparent cost of
Cal_CalDate so that Cal_CtofcNo can take precedence.

Best Regards, Simon Riggs






pgsql-performance by date:

Previous
From: Simon Riggs
Date:
Subject: Re: BETWEEN optimizer problems with single-value
Next
From: Jan de Visser
Date:
Subject: Re: Slow SELECTS after large update cycle