Re: Constraint Exclusion on all tables
От | Tatsuo Ishii |
---|---|
Тема | Re: Constraint Exclusion on all tables |
Дата | |
Msg-id | 20050724.175717.104031390.t-ishii@sra.co.jp обсуждение исходный текст |
Ответ на | Constraint Exclusion on all tables (Simon Riggs <simon@2ndquadrant.com>) |
Ответы |
Re: Constraint Exclusion on all tables
|
Список | pgsql-hackers |
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 >
В списке pgsql-hackers по дате отправления: