Re: planner support functions: handle GROUP BY estimates ? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: planner support functions: handle GROUP BY estimates ?
Date
Msg-id 1009.1579038764@sss.pgh.pa.us
Whole thread Raw
In response to Re: planner support functions: handle GROUP BY estimates ?  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Responses Re: planner support functions: handle GROUP BY estimates ?  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
List 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 by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: planner support functions: handle GROUP BY estimates ?
Next
From: Alvaro Herrera
Date:
Subject: Re: aggregate crash