Thread: ITYM DROP TABLE
I was reading the partitioning docs when I spotted this. I think it means to highlight the advantages of DROP TABLE
overDELETE rather than ALTER TABLE.
Best,
David
diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml
index 4c9fc5d..0cdb800 100644
*** a/doc/src/sgml/ddl.sgml
--- b/doc/src/sgml/ddl.sgml
*************** VALUES ('New York', NULL, NULL, 'NY');
*** 2332,2338 **** <para> Bulk loads and deletes can be accomplished by adding or removing partitions,
ifthat requirement is planned into the partitioning design.
! <command>ALTER TABLE</> is far faster than a bulk operation. It also entirely avoids the
<command>VACUUM</command> overhead caused by a bulk <command>DELETE</>. </para>
--- 2332,2338 ---- <para> Bulk loads and deletes can be accomplished by adding or removing partitions,
ifthat requirement is planned into the partitioning design.
! <command>DROP TABLE</> is far faster than a bulk operation. It also entirely avoids the
<command>VACUUM</command> overhead caused by a bulk <command>DELETE</>. </para>
On Mon, Jun 13, 2011 at 5:44 PM, David E. Wheeler <david@kineticode.com> wrote: > I was reading the partitioning docs when I spotted this. I think it means to highlight the advantages of DROP TABLE overDELETE rather than ALTER TABLE. I guess they might mean ALTER TABLE .. NO INHERIT. But I think I agree that DROP TABLE would be better. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Excerpts from David E. Wheeler's message of lun jun 13 17:44:05 -0400 2011:
> I was reading the partitioning docs when I spotted this. I think it means to highlight the advantages of DROP TABLE
overDELETE rather than ALTER TABLE.
I think the point of the existing wording is to point out
ALTER TABLE / NO INHERIT. I wonder if it's worth expanding the text to
mention both, such as
--- a/doc/src/sgml/ddl.sgml
+++ b/doc/src/sgml/ddl.sgml
@@ -2320,7 +2320,9 @@ VALUES ('New York', NULL, NULL, 'NY'); <para> Bulk loads and deletes can be accomplished
byadding or removing partitions, if that requirement is planned into the partitioning design.
- <command>ALTER TABLE</> is far faster than a bulk operation.
+ <command>ALTER TABLE</> (to split out a sub-table from the partitioned
+ table) and <command>DROP TABLE</> (to remove a partition altogether) are
+ both far faster than a bulk operation. It also entirely avoids the <command>VACUUM</command> overhead
causedby a bulk <command>DELETE</>. </para>
However, this introductory text is supposed to be very brief; maybe we
should remove mention of specific commands here.
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Excerpts from David E. Wheeler's message of lun jun 13 17:44:05 -0400 2011:
>> I was reading the partitioning docs when I spotted this. I think it means to highlight the advantages of DROP TABLE
overDELETE rather than ALTER TABLE.
> I think the point of the existing wording is to point out
> ALTER TABLE / NO INHERIT. I wonder if it's worth expanding the text to
> mention both, such as
> - <command>ALTER TABLE</> is far faster than a bulk operation.
> + <command>ALTER TABLE</> (to split out a sub-table from the partitioned
> + table) and <command>DROP TABLE</> (to remove a partition altogether) are
> + both far faster than a bulk operation.
I think you need to spell out "ALTER TABLE NO INHERIT" if you are going
to do that. This formulation seems to imply that *any* form of ALTER
TABLE is fast, which surely ain't the truth.
> However, this introductory text is supposed to be very brief; maybe we
> should remove mention of specific commands here.
No, I don't think it needs to be that brief. But if you think your
version is too long, remove the parenthetical remarks.
regards, tom lane
On Jun 14, 2011, at 8:03 AM, Tom Lane wrote: >> - <command>ALTER TABLE</> is far faster than a bulk operation. >> + <command>ALTER TABLE</> (to split out a sub-table from the partitioned >> + table) and <command>DROP TABLE</> (to remove a partition altogether) are >> + both far faster than a bulk operation. > > I think you need to spell out "ALTER TABLE NO INHERIT" if you are going > to do that. This formulation seems to imply that *any* form of ALTER > TABLE is fast, which surely ain't the truth. > >> However, this introductory text is supposed to be very brief; maybe we >> should remove mention of specific commands here. > > No, I don't think it needs to be that brief. But if you think your > version is too long, remove the parenthetical remarks. +1 I think that would be perfect. Best, David
Excerpts from David E. Wheeler's message of mar jun 14 12:33:27 -0400 2011: > On Jun 14, 2011, at 8:03 AM, Tom Lane wrote: > > >> - <command>ALTER TABLE</> is far faster than a bulk operation. > >> + <command>ALTER TABLE</> (to split out a sub-table from the partitioned > >> + table) and <command>DROP TABLE</> (to remove a partition altogether) are > >> + both far faster than a bulk operation. > > > > I think you need to spell out "ALTER TABLE NO INHERIT" if you are going > > to do that. This formulation seems to imply that *any* form of ALTER > > TABLE is fast, which surely ain't the truth. > > > >> However, this introductory text is supposed to be very brief; maybe we > >> should remove mention of specific commands here. > > > > No, I don't think it needs to be that brief. But if you think your > > version is too long, remove the parenthetical remarks. > > +1 I think that would be perfect. Done that way (9.0 and beyond). -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Done that way (9.0 and beyond).
Re-reading the actual commit, I notice that there's now a grammatical
problem: the following sentence says
It also entirely avoids the <command>VACUUM</command> overhead caused by a bulk <command>DELETE</>.
which was okay when "it" referred to "ALTER TABLE", but now that there
are two commands mentioned in the previous sentence, it doesn't match.
Perhaps "These commands also avoid the ...".
regards, tom lane
On Mon, Jun 13, 2011 at 10:44 PM, David E. Wheeler <david@kineticode.com> wrote:
> I was reading the partitioning docs when I spotted this. I think it means to highlight the advantages of DROP TABLE
overDELETE rather than ALTER TABLE.
>
> Best,
>
> David
>
> diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml
> index 4c9fc5d..0cdb800 100644
> *** a/doc/src/sgml/ddl.sgml
> --- b/doc/src/sgml/ddl.sgml
> *************** VALUES ('New York', NULL, NULL, 'NY');
> *** 2332,2338 ****
> <para>
> Bulk loads and deletes can be accomplished by adding or removing
> partitions, if that requirement is planned into the partitioning design.
> ! <command>ALTER TABLE</> is far faster than a bulk operation.
> It also entirely avoids the <command>VACUUM</command>
> overhead caused by a bulk <command>DELETE</>.
> </para>
> --- 2332,2338 ----
> <para>
> Bulk loads and deletes can be accomplished by adding or removing
> partitions, if that requirement is planned into the partitioning design.
> ! <command>DROP TABLE</> is far faster than a bulk operation.
> It also entirely avoids the <command>VACUUM</command>
> overhead caused by a bulk <command>DELETE</>.
> </para>
That looks weird. I'm sure that *used* to say DROP TABLE.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Excerpts from Tom Lane's message of mar jun 14 13:04:30 -0400 2011: > Alvaro Herrera <alvherre@commandprompt.com> writes: > > Done that way (9.0 and beyond). > > Re-reading the actual commit, I notice that there's now a grammatical > problem: the following sentence says > > It also entirely avoids the <command>VACUUM</command> > overhead caused by a bulk <command>DELETE</>. > > which was okay when "it" referred to "ALTER TABLE", but now that there > are two commands mentioned in the previous sentence, it doesn't match. > Perhaps "These commands also avoid the ...". Yeah, fixed. -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support