Re: Introducing floating point cast into filter drastically changes row estimate

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: Introducing floating point cast into filter drastically changes row estimate
Дата
Msg-id CAHyXU0yLQpshj5mgF_2zzjyKqmrniMqhzrbpBd7SZ1MD2UO=dQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Introducing floating point cast into filter drastically changes row estimate  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Introducing floating point cast into filter drastically changes row estimate  (Merlin Moncure <mmoncure@gmail.com>)
Список pgsql-bugs
On Wed, Oct 24, 2012 at 3:33 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Merlin Moncure <mmoncure@gmail.com> writes:
>> Yeah -- I have a case where a large number of joins are happening that
>> have a lot of filtering based on expressions and things like that.
>
> Might be worth your while to install some indexes on those expressions,
> if only to trigger collection of stats about them.

Not practical -- these expressions are all about 'outlier culling'.
It's just wasteful to materialize indexes for stastical purposes only.
 Anyways, in this case, I just refactored the query into a CTE.

Hm -- what if you could flag a table dependent expression for being
interesting for statistics?  Or what about planner hints for boolean
expressions (ducks) ... 'likely(boolexpr)'?

merlin

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Introducing floating point cast into filter drastically changes row estimate
Следующее
От: Merlin Moncure
Дата:
Сообщение: Re: Introducing floating point cast into filter drastically changes row estimate