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
