Re: [PATCHES] Partitioning docs - Mailing list pgsql-docs

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
>
> - "—" 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