Re: Multi-column distinctness.
От | Simon Riggs |
---|---|
Тема | Re: Multi-column distinctness. |
Дата | |
Msg-id | CANP8+jKYMtUb8T0Oc1QKPEbfYG+Q9y9vH2Mb_=k5uKyOwyeNxg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Multi-column distinctness. (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On 20 October 2015 at 11:59, Tom Lane <tgl@sss.pgh.pa.us> wrote:
--
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Oct 20, 2015 at 10:51 AM, Tomas Vondra
> <tomas.vondra@2ndquadrant.com> wrote:
>>>> 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.
> But ADD is no better there. I think ALTER TABLE .. COLLECT STATISTICS
> isn't any worse than ALTER TABLE ... CLUSTER ON index_name. In both
> cases, it means, when you do this operation, do it this way.
> I would suggest that instead of DROP or REMOVE, the opposite should be
> ALTER TABLE .. NO COLLECT STATISTICS.
Why is this an improvement over using already-existing keywords?
The earlier patch changed the grammar for the DROP (column) subcommand, which I am saying is not acceptable.
So by using an alternate keyword we are able to keep the existing syntax untouched.
I suggested the word COLLECT since that is another word commonly used in conjunction with STATISTICS (at least in DB2 and Teradata).
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: