Re: Improve selectivity estimate for range queries - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Improve selectivity estimate for range queries
Date
Msg-id 18710.1547157810@sss.pgh.pa.us
Whole thread Raw
In response to Re: Improve selectivity estimate for range queries  (Robert Haas <robertmhaas@gmail.com>)
Responses RE: Improve selectivity estimate for range queries  ("Yuzuko Hosoya" <hosoya.yuzuko@lab.ntt.co.jp>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Dec 21, 2018 at 11:50 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> A smaller-footprint way to fix the immediate problem might be to
>> change the values of DEFAULT_INEQ_SEL and friends so that they're
>> even less likely to be matched by accident.  That is, instead of
>> 0.3333333333333333, use 0.333333333333342 or some such.

> That's not a dumb idea, but it seems pretty unprincipled to me, and to
> be honest I'm kind of surprised that you're not proposing something
> cleaner.

The problem is the invasiveness of such a change (large) vs the benefit
(not so large).  The upthread patch attempted to add a separate signaling
path, but it was very incomplete --- and yet both I and Horiguchi-san
thought it was already too messy.

Maybe at some point we'll go over to something reasonably principled,
like adding confidence intervals to all selectivity estimates.  That
would be *really* invasive but perhaps would bring enough benefit to
justify itself.  But the current patch is just attempting to fix one
extremely narrow pain point, and if that is all it's doing it should
have a commensurately small footprint.  So I don't think the submitted
patch looks good from a cost/benefit standpoint.

            regards, tom lane


pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: speeding up planning with partitions
Next
From: John Naylor
Date:
Subject: Re: WIP: Avoid creation of the free space map for small tables