Re: GIN indexscans versus equality selectivity estimation - Mailing list pgsql-hackers

From Tom Lane
Subject Re: GIN indexscans versus equality selectivity estimation
Date
Msg-id 25450.1294673112@sss.pgh.pa.us
Whole thread Raw
In response to Re: GIN indexscans versus equality selectivity estimation  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: GIN indexscans versus equality selectivity estimation  (Josh Berkus <josh@agliodbs.com>)
Re: GIN indexscans versus equality selectivity estimation  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Sun, Jan 9, 2011 at 6:38 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> or we could hack eqsel() to bound the no-stats estimate to a bit less
>> than 1.

> This seems like a pretty sensible thing to do.  I can't immediately
> imagine a situation in which 1.0 is a sensible selectivity estimate in
> the no-stats case and 0.90 (say) is a major regression.

After sleeping on it, that seems like my least favorite option.  It's
basically a kluge, as is obvious because there's no principled way to
choose what the bound is (or the minimum result from
get_variable_numdistinct, if we were to hack it there).  I'm currently
leaning to the idea of tweaking the logic in indxpath.c; in particular,
why wouldn't it be a good idea to force consideration of the bitmap path
if the index type hasn't got amgettuple?  If we don't, then we've
completely wasted the effort spent up to that point inside
find_usable_indexes.

Or we could just ignore the issue; as Josh says, that's not an
unreasonable option.  The particular case I ran into is certainly not
too compelling.  I'm a bit worried though that there might be other
cases where the estimator comes up with 1.0 selectivity but it'd still
be worth considering a bitmap scan.
        regards, tom lane


pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: SSI and 2PC
Next
From: Simon Riggs
Date:
Subject: Re: system views for walsender activity