Skip site navigation (1) Skip section navigation (2)

Re: [PATCHES] Partitioning docs

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: pgsql-patches(at)postgresql(dot)org, pgsql-docs(at)postgresql(dot)org
Subject: Re: [PATCHES] Partitioning docs
Date: 2005-11-02 19:55:18
Message-ID: 1130961318.8300.1794.camel@localhost.localdomain (view raw or flat)
Thread:
Lists: pgsql-docspgsql-patches
On Tue, 2005-11-01 at 18:19 -0500, Neil Conway wrote:
> 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
> 
> - "&mdash;" is an em dash, "--" and "---" are not
> 
> - "indexes", not "indices"

Thanks very much for a thorough review.

> - Why "Constraint Exclusion" (or worse, "the Constraint Exclusion
> feature") rather than simply "constraint exclusion"? 

OK

> (I'm not even sure
> it's a good idea to mention this term in end-user documentation.)

We now have a parameter called constraint_exclusion, so the term already
exists and so requires explanation. I would have had no objection to
modifications of that term, but it has been in use now for 4 months, so
changing it doesn't seem practical.

> - 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).

Trying to identify which bit of advice you refer to.... I put some
comments in based upon feedback from the beta on specific queries that
were not optimised the same as non-inherited tables. If thats what
you're talking about, then I'd like to put that back. The manuals aren't
written for you and me; why let others stumble when they could have it
in black and white?

> + 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?

Yes. ....What generic term would you use for query compilation? query
preparation? The distinction of parsing/planning/optimization etc is
lost on most people.

> + <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.

OK, I'll work on a longer explanation of that.

> 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.

Best Regards, Simon Riggs



In response to

Responses

pgsql-docs by date

Next:From: Neil ConwayDate: 2005-11-02 23:57:39
Subject: Re: [PATCHES] Partitioning docs
Previous:From: Neil ConwayDate: 2005-11-01 23:19:37
Subject: Re: Partitioning docs

pgsql-patches by date

Next:From: Tom LaneDate: 2005-11-02 20:09:45
Subject: Re: [HACKERS] Reducing the overhead of NUMERIC data
Previous:From: Simon RiggsDate: 2005-11-02 19:36:19
Subject: Re: [HACKERS] Reducing the overhead of NUMERIC data

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group