Re: Improve selectivity estimate for range queries

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Improve selectivity estimate for range queries
Дата
Msg-id 18710.1547157810@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Improve selectivity estimate for range queries  (Robert Haas <robertmhaas@gmail.com>)
Ответы RE: Improve selectivity estimate for range queries  ("Yuzuko Hosoya" <hosoya.yuzuko@lab.ntt.co.jp>)
Список 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 по дате отправления:

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: speeding up planning with partitions
Следующее
От: John Naylor
Дата:
Сообщение: Re: WIP: Avoid creation of the free space map for small tables