Re: Multi-column distinctness. - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Multi-column distinctness.
Date
Msg-id CANP8+jLnK2z9R7hVBLbib+ZShO8XaX=gw-nyUnYRcnZrToTLYA@mail.gmail.com
Whole thread Raw
In response to Re: Multi-column distinctness.  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Responses Re: Multi-column distinctness.  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
List pgsql-hackers
On 20 October 2015 at 16:48, Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote:
 
and I can get this to work too

                        | DROP STATISTICS ON '(' name_list ')'

if I expand out the "DROP opt_column" productions to be two separate
productions with and without COLUMN, as was done long ago for ADD
COLUMN.

These also work without ON, actually, though it does not work to
leave out the parens. (I think that has to do with the conflict
against multiple ALTER TABLE subcommands, not against ADD COLUMN.)

It doesn't look like we could easily stick a "name" in between
STATISTICS and ON, but I'm unconvinced that that's necessary.

Well, it's definitely easier to reference the statistics by name (e.g. in the DROP command).

Can't we just insist that there be only one statistics declaration
for a given column list?

I would rather not, because I envision preferring different types of statistics for different types of queries. For example the statistics discussed in this particular thread only supports equality clauses, so this restriction would mean we can't also define histogram, we'll be unable to estimate queries with ranges.

Can we do something like this...

ADD STATISTICS ON (col list) USING (histogram, MFV)
 
so we have Types/Methods of statistic, rather than specific names for the statistic entry?

Since this command doesn't actually ADD the statistics, it just creates a specification used by the next ANALYZE, it would seem better to use a different keyword than ADD, perhaps DECLARE STATISTICS ON... and DROP STATISTICS ON

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

pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Multi-column distinctness.
Next
From: Lukas Fittl
Date:
Subject: Re: SuperUser check in pg_stat_statements