Re: planner support functions: handle GROUP BY estimates ?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: planner support functions: handle GROUP BY estimates ?
Дата
Msg-id 1009.1579038764@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: planner support functions: handle GROUP BY estimates ?  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Ответы Re: planner support functions: handle GROUP BY estimates ?
Список pgsql-hackers
Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
> On Tue, Jan 14, 2020 at 04:21:57PM -0500, Tom Lane wrote:
>> Yeah, it seems likely to me that the infrastructure for this would be
>> somewhat different --- the user-facing syntax could be basically the
>> same, but ultimately we want to generate entries in pg_statistic not
>> pg_statistic_ext_data.  Or at least entries that look the same as what
>> you could find in pg_statistic.

> Yeah. I think we could invent a new type of statistics "expressions"
> which would simply built this per-column stats. So for example
>    CREATE STATISTICS s (expressions) ON (a*b), sqrt(c) FROM t;

I was imagining the type keyword as being "standard" or something
like that, since what it's going to build are the "standard" kinds
of stats for the expression's datatype.  But yeah, has to be some other
keyword than the existing ones.

The main issue for sticking the results into pg_statistic is that
the primary key there is (starelid, staattnum), and we haven't got
a suitable attnum.  I wouldn't much object to putting the data into
pg_statistic_ext_data, but it doesn't really have a suitable
rowtype ...

            regards, tom lane



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

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: planner support functions: handle GROUP BY estimates ?
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: aggregate crash