From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Minor correction in alter_table.sgml |
Date: | 2016-11-30 16:17:10 |
Message-ID: | 19669.1480522630@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Stephen Frost <sfrost(at)snowman(dot)net> writes:
> Seems like this would be a bit better:
> ------
> All the actions, when acting on a single table and not using the ALL IN
> TABLESPACE form, except RENAME and SET SCHEMA, can be combined into a
> list of multiple alterations to be applied.
> ------
> I note that we say 'in parallel', but given that we have actual parallel
> operations now, we should probably shy away from using that except in
> cases where we actually mean operations utilizing multiple parallel
> processes.
I follow your beef with use of the word "parallel", but your proposed
rewording loses the entire point of multiple actions per ALTER TABLE;
namely that they're accomplished without repeated scans of the table.
Also the above seems a bit clunky; doesn't ALL IN TABLESPACE fall outside
the restriction "acting on a single table"?
So maybe something like
All the forms of ALTER TABLE that act on a single table,
except RENAME and SET SCHEMA, can be combined into a
list of multiple alterations to be applied together.
We would have to enlarge on what "together" means, but I think there may
already be text explaining that further down.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2016-11-30 16:19:35 | Re: Mail thread references in commits |
Previous Message | Amit Langote | 2016-11-30 15:56:14 | Re: Declarative partitioning - another take |