Re: planner support functions: handle GROUP BY estimates ?

On Tue, Jan 14, 2020 at 05:37:53PM -0500, Tom Lane wrote:
>Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> writes:
>> On Tue, Jan 14, 2020 at 04:52:44PM -0500, Tom Lane wrote:
>>> 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.
>
>Seems pretty yucky. I realize we've already got "fake relations" like
>foreign tables and composite types, but the number of special cases
>those create is very annoying. And you still don't have anyplace to
>put the expressions themselves in such a structure --- I hope you
>weren't going to propose fake pg_index rows for that.
>

No, I wasn't going to propose fake pg_index rows, because - I actually
wrote "stored either in pg_statistic_ext or in a new catalog" so I was
thinking about a new catalog (so a dedicated and simplified copy of
pg_index).

>I wonder just how messy it would be to add a column to pg_statistic_ext
>whose type is the composite type "pg_statistic", and drop the required
>data into that. We've not yet used any composite types in the system
>catalogs, AFAIR, but since pg_statistic_ext isn't a bootstrap catalog
>it seems like we might be able to get away with it.
>

I don't know, but feels a bit awkward to store this type of stats into
pg_statistic_ext, which was meant for multi-column stats. Maybe it'd
work fine, not sure.

regards

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