Re: planner support functions: handle GROUP BY estimates ?

On Tue, Jan 14, 2020 at 04:52:44PM -0500, Tom Lane wrote:
>Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)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 ...

Well, that's why I proposed to essentially build a fake "relation" just
for this purpose. So we'd have a pg_class entry with a special relkind,
attnums and all that. And the expressions would be stored either in
pg_statistic_ext or in a new catalog. But maybe that's nonsense.

regards

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services