Re: Improve selectivity estimate for range queries

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Improve selectivity estimate for range queries
Дата
Msg-id CA+Tgmoa7RBEsfv+n+tm6CpKU365Bv1=a_Z+W6VvCo6jdt-oJrA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Improve selectivity estimate for range queries  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Improve selectivity estimate for range queries  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
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.  It might
> seem that that's just moving the problem around, but I think it
> might be possible to show that such a value couldn't be computed
> by scalarltsel given a histogram with no more than 10000 members.
> (I haven't tried to actually prove that, but it seems intuitive
> that the set of possible results would be quantized with no more
> than about 5 digits precision.

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.  If you admit the need to distinguish between real estimates
and last-ditch ones, why shouldn't we have an explicit representation
of that rather than trying to pick a last-ditch value that is unlikely
to be confused with a real one?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Commitfest delayed: extend it?
Следующее
От: Robert Haas
Дата:
Сообщение: Re: add_partial_path() may remove dominated path but still in use