Re: Multi-column distinctness.

From: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Multi-column distinctness.
Date: 2015-10-20 14:51:38
Message-ID: 562654FA.7000607@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 10/20/2015 01:14 PM, Simon Riggs wrote:
> On 19 October 2015 at 20:16, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com
> <mailto:tomas(dot)vondra(at)2ndquadrant(dot)com>> wrote:
>
> Hello Kyotaro-san,
>
> On 09/11/2015 06:58 PM, Tomas Vondra wrote:
> >
>
> Maybe the best solution is to abandon the ALTER TABLE approach
> entirely, and instead invent a new set of commands
>
> CREATE STATISTICS
> DROP STATISTICS
>
> (ALTER STATISTICS seems a bit excessive at this point).
>
> Another thing is that perhaps we should add names for statistics,
> just like we do for constraints, for example. Otherwise the DROP
> STATISTICS handling is rather awkward - for example if the user
> creates stats twice by mistake, he's unable to drop just one of
> them.
>
>
> Do you think this modified syntax makes sense? I'll have time to
> hack on this over the next few days.
>
>
> Koyotaro's changes to force COLUMN to be required won't get through.
>
> ISTM that we could use COLLECT STATISTICS instead of ADD STATISTICS, and
> use REMOVE STATISTICS instead of DROP STATISTICS. That way we can use
> ALTER TABLE rather than inventing a new command. 5 minute change...

That seems like a neat idea, actually. I'm not sure COLLECT is a good
choice as it suggest the statistics is actually built, but that only
happens during ANALYZE. But otherwise this seems to solve the issues
with keywords and it's quite simple.

>
> Unless there is some better reason for a whole new command?

Not really. The other proposal (adding names for statistics) does not
require new command. The one thing that would require new command is
building statistics on multiple tables (for join estimation), but I
don't have any idea of how that would actually work.

regards

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2015-10-20 14:52:05 Re: ROWS FROM(): A Foolish (In)Consistency?
Previous Message Robert Haas 2015-10-20 14:50:39 Re: [PATCH] SQL function to report log message