Re: planner support functions: handle GROUP BY estimates ?
От | Tomas Vondra |
---|---|
Тема | Re: planner support functions: handle GROUP BY estimates ? |
Дата | |
Msg-id | 20200114231913.4yuodxc7o3qpqi3n@development обсуждение исходный текст |
Ответ на | Re: planner support functions: handle GROUP BY estimates ? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: planner support functions: handle GROUP BY estimates ?
|
Список | pgsql-hackers |
On Tue, Jan 14, 2020 at 05:37:53PM -0500, Tom Lane wrote: >Tomas Vondra <tomas.vondra@2ndquadrant.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
В списке pgsql-hackers по дате отправления: