From: | Neil Conway <neilc(at)samurai(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | pgsql-patches(at)postgresql(dot)org, pgsql-docs(at)postgresql(dot)org |
Subject: | Re: Partitioning docs |
Date: | 2005-11-01 23:19:37 |
Message-ID: | 1130887177.6884.38.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs 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 | Content-Type | Size |
---|---|---|
ce5.patch | text/x-patch | 38.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2005-11-02 19:55:18 | Re: [PATCHES] Partitioning docs |
Previous Message | Simon Riggs | 2005-11-01 07:19:51 | Re: [PATCHES] Partitioning docs |
From | Date | Subject | |
---|---|---|---|
Next Message | J. Andrew Rogers | 2005-11-02 01:46:10 | Re: Reducing the overhead of NUMERIC data |
Previous Message | Tom Lane | 2005-11-01 23:15:49 | Re: Reducing the overhead of NUMERIC data |