Re: [HACKERS] ITYM DROP TABLE

2011-06-14 Thread Robert Haas
On Mon, Jun 13, 2011 at 5:44 PM, David E. Wheeler da...@kineticode.com wrote:
 I was reading the partitioning docs when I spotted this. I think it means to 
 highlight the advantages of DROP TABLE over DELETE 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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] ITYM DROP TABLE

2011-06-14 Thread Alvaro Herrera
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 over DELETE 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 by adding or removing
   partitions, if that requirement is planned into the partitioning design.
-  commandALTER TABLE/ is far faster than a bulk operation.
+  commandALTER TABLE/ (to split out a sub-table from the partitioned
+  table) and commandDROP TABLE/ (to remove a partition altogether) are
+  both far faster than a bulk operation.
   It also entirely avoids the commandVACUUM/command
   overhead caused by a bulk commandDELETE/.
  /para


However, this introductory text is supposed to be very brief; maybe we
should remove mention of specific commands here.

-- 
Álvaro Herrera alvhe...@commandprompt.com
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] ITYM DROP TABLE

2011-06-14 Thread Tom Lane
Alvaro Herrera alvhe...@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 over DELETE 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

 -  commandALTER TABLE/ is far faster than a bulk operation.
 +  commandALTER TABLE/ (to split out a sub-table from the partitioned
 +  table) and commandDROP 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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] ITYM DROP TABLE

2011-06-14 Thread David E. Wheeler
On Jun 14, 2011, at 8:03 AM, Tom Lane wrote:

 -  commandALTER TABLE/ is far faster than a bulk operation.
 +  commandALTER TABLE/ (to split out a sub-table from the partitioned
 +  table) and commandDROP 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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] ITYM DROP TABLE

2011-06-14 Thread Alvaro Herrera
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:
 
  -  commandALTER TABLE/ is far faster than a bulk operation.
  +  commandALTER TABLE/ (to split out a sub-table from the 
  partitioned
  +  table) and commandDROP 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 alvhe...@commandprompt.com
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] ITYM DROP TABLE

2011-06-14 Thread Tom Lane
Alvaro Herrera alvhe...@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 commandVACUUM/command
   overhead caused by a bulk commandDELETE/.

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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] ITYM DROP TABLE

2011-06-14 Thread Simon Riggs
On Mon, Jun 13, 2011 at 10:44 PM, David E. Wheeler da...@kineticode.com wrote:
 I was reading the partitioning docs when I spotted this. I think it means to 
 highlight the advantages of DROP TABLE over DELETE 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.
 !       commandALTER TABLE/ is far faster than a bulk operation.
        It also entirely avoids the commandVACUUM/command
        overhead caused by a bulk commandDELETE/.
       /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.
 !       commandDROP TABLE/ is far faster than a bulk operation.
        It also entirely avoids the commandVACUUM/command
        overhead caused by a bulk commandDELETE/.
       /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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] ITYM DROP TABLE

2011-06-14 Thread Alvaro Herrera
Excerpts from Tom Lane's message of mar jun 14 13:04:30 -0400 2011:
 Alvaro Herrera alvhe...@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 commandVACUUM/command
overhead caused by a bulk commandDELETE/.
 
 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 alvhe...@commandprompt.com
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


[HACKERS] ITYM DROP TABLE

2011-06-13 Thread David E. Wheeler
I was reading the partitioning docs when I spotted this. I think it means to 
highlight the advantages of DROP TABLE over DELETE 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.
!   commandALTER TABLE/ is far faster than a bulk operation.
It also entirely avoids the commandVACUUM/command
overhead caused by a bulk commandDELETE/.
   /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.
!   commandDROP TABLE/ is far faster than a bulk operation.
It also entirely avoids the commandVACUUM/command
overhead caused by a bulk commandDELETE/.
   /para


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers