Thread

Re: Constraint Exclusion on all tables

Tatsuo Ishii <t-ishii@sra.co.jp> — 2005-07-24T08:57:17Z

It seems current CE implementation ignores UPDATE, DELETE quries. Is
this an intended limitation?
--
Tatsuo Ishii

> 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
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
>        subscribe-nomail command to majordomo@postgresql.org so that your
>        message can get through to the mailing list cleanly
>