Tomas Vondra <tomas.von...@2ndquadrant.com> writes: > On Tue, Jan 14, 2020 at 05:37:53PM -0500, Tom Lane wrote: >> 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 meant pg_statistic_ext_data, obviously ] > 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. If we wanted to allow a single statistics object to contain data for multiple expressions, we'd actually need that to be array-of-pg_statistic not just pg_statistic. Seems do-able, but on the other hand we could just prohibit having more than one output column in the "query" for this type of extended statistic. Either way, this seems far less invasive than either a new catalog or a new relation relkind (to say nothing of needing both, which is where you seemed to be headed). regards, tom lane