Re: Partitioning docs - Mailing list pgsql-patches

From Neil Conway
Subject Re: Partitioning docs
Date
Msg-id 1130887177.6884.38.camel@localhost.localdomain
Whole thread Raw
In response to Re: Partitioning docs  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: Partitioning docs  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-patches
On Mon, 2005-31-10 at 22:41 +0000, Simon Riggs wrote:
> I believe this is now complete and ready for application.

Comments:

- INSERT, UPDATE, etc. should be marked with <command/>, unless <xref/>
would be more appropriate

- The names of GUC variables should be marked up with <varname/>, unless
<xref/> would be more appropriate

- <xref> tags that link to the reference page of an SQL command should
be of the form: <xref linkend="sql-..." endterm="sql-...-title"> -- the
endterm attribute should not be omitted.

- "PostgreSQL" should be marked-up with <productname/>

- In text like "You can use RULEs to ...", "rules" would be better.

- The word following a colon should not be capitalized

- "—" is an em dash, "--" and "---" are not

- "indexes", not "indices"

- Why "Constraint Exclusion" (or worse, "the Constraint Exclusion
feature") rather than simply "constraint exclusion"? (I'm not even sure
it's a good idea to mention this term in end-user documentation.)

- I removed a few statements and paragraphs I thought were unnecessary
(e.g. Postgres was the first DBMS to have inheritance, some vague and
IMHO useless advice about query optimization differences with inherited
tables, etc.). Feel free to resubmit them if you disagree (although
perhaps not for 8.1.0).

+ All constraints on all partitions of the master table are considered
for
+ Constraint Exclusion, so large numbers of partitions are likely to
+ increase query parse time considerably.

Wouldn't it primarily increase planning time, not parsing time?

+ <para>
+  CE only works when the query directly matches a constant. A
+  constant bound to a parameterised query will not work in the same way
+  since the plan is fixed and would need to vary with each execution.
+  Also, stable constants such as CURRENT_DATE may not be used, since
+  these are constant only for during the execution of a single query.
+  Joins conditions will not allow CE to work either.
+ </para>

I'm not sure what the last sentence is intended to mean.

Revised patch attached and applied. There are at least a few more things
that need cleaning up -- if no one beats me to it I'll do that shortly.

-Neil


Attachment

pgsql-patches by date:

Previous
From: Marko Kreen
Date:
Subject: pgcrypto doc polish
Next
From: Alvaro Herrera
Date:
Subject: tsearch2 makefile fixes