Re: Do we still need constraint_exclusion? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Do we still need constraint_exclusion?
Date
Msg-id 13476.1231350875@sss.pgh.pa.us
Whole thread Raw
In response to Re: Do we still need constraint_exclusion?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Do we still need constraint_exclusion?  (Bruce Momjian <bruce@momjian.us>)
Re: Do we still need constraint_exclusion?  ("Robert Haas" <robertmhaas@gmail.com>)
Re: Do we still need constraint_exclusion?  (Stephen Frost <sfrost@snowman.net>)
Re: Do we still need constraint_exclusion?  (Josh Berkus <josh@agliodbs.com>)
Re: Do we still need constraint_exclusion?  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
I wrote:
> I just thought of a possible compromise though: maybe we could invent an
> intermediate constraint_exclusion setting that makes the checks only for
> inheritance-child tables.  This would avoid the overhead for simple
> queries and still get the benefit for most of the cases where it's
> actually useful.  I'm not sure how hard this'd be to shoehorn into the
> planner, ...

Actually, it looks like it'd be totally trivial to implement: just check
rel->reloptkind == RELOPT_OTHER_MEMBER_REL to detect whether we're
looking at an inheritance child.  (Actually this would also succeed
for a UNION ALL member, but that's good because that's the other case
where constraint exclusion is more likely to be useful.)

So, barring objections, I'll go make this happen.  What do we want to
call the intermediate constraint_exclusion value?  The first thing
that comes to mind is constraint_exclusion = 'child', but perhaps
someone has a better idea.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: Do we still need constraint_exclusion?
Next
From: Bruce Momjian
Date:
Subject: Re: Do we still need constraint_exclusion?