Re: GIN indexscans versus equality selectivity estimation

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: GIN indexscans versus equality selectivity estimation
Дата
Msg-id 25450.1294673112@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: GIN indexscans versus equality selectivity estimation  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: GIN indexscans versus equality selectivity estimation  (Josh Berkus <josh@agliodbs.com>)
Re: GIN indexscans versus equality selectivity estimation  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: David Fetter
Дата:
Сообщение: Re: SSI and 2PC
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: system views for walsender activity