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 по дате отправления: