Constraint Exclusion on all tables - Mailing list pgsql-hackers

From Simon Riggs
Subject Constraint Exclusion on all tables
Date
Msg-id 1121808229.3998.6.camel@localhost.localdomain
Whole thread Raw
Responses Re: Constraint Exclusion on all tables  ("Jim C. Nasby" <decibel@decibel.org>)
Re: Constraint Exclusion on all tables  (Tatsuo Ishii <t-ishii@sra.co.jp>)
List pgsql-hackers
So far, the CE patch covers only inherited child tables and is only
effective when enable_constraint_exclusion is true.

There have been various requests for this to work with UNION ALL views
and also with normal queries.

Since we have a GUC that can turn this behaviour off, and is off by
default, I think it is probably acceptable to have CE apply to ALL table
accesses, not just inherited ones. That is considerably neater in
implementation than trying to kludge it for UNION ALL cases.

[In the future when we have plan invalidation: I would suggest that we
keep enable_constraint_exclusion as a GUC. When set to true, this would
apply for all tables. Inherited tables would always be considered for
exclusion, whatever the setting of the GUC.]

An idea for discussion is to hide the exclusion within
set_plain_rel_pathlist, so that CE applies to all tables. If a table is
excluded, we generate only the single "exclusion plan". I think we
should introduce a new Node type of "No Scan", making it very clear in
any Explain that we have excluded a table. The alternative is a Result
node with an SeqScan below it... but the Result doesn't explain *why* it
exists at that point. I've already used that form of coding and it works
well enough.

Inheritance queries would continue to act as they do now, where an
excluded table is *not* shown; this is to allow for sensible size
EXPLAINs when we have 100s of child tables.

Comments?

Best Regards, Simon Riggs



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: [PATCHES] Patch to fix plpython on OS X
Next
From: "Jim C. Nasby"
Date:
Subject: Re: [PATCHES] Patch to fix plpython on OS X