Re: Exclusion Constraint vs. Constraint Exclusion

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>, David Fetter <david(at)fetter(dot)org>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Exclusion Constraint vs. Constraint Exclusion
Date: 2009-12-08 03:01:13
Message-ID: 603c8f070912071901h792092a5x96c1851c61ddb9aa@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Dec 7, 2009 at 9:12 PM, Alvaro Herrera
<alvherre(at)commandprompt(dot)com> wrote:
> Tom Lane wrote:
>> Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
>> > If we do need to do this, perhaps we should change the older parameter
>> > to be partition_exclusion.
>>
>> Yeah, if we do want to do something about this then changing the name of
>> the existing GUC would be a lot less work.  However, partition_exclusion
>> seems to imply that it *only* applies to partitioned tables, which is
>> not the case...
>
> Perhaps
> table_exclusion = {on, off, partition}
>
> Of course, constraint_exclusion should continue to work as a synonym for
> backwards compatibility, but it wouldn't be documented.

This seems pretty horrible to me. I'm not sure whether the current
code supports excluding appendrel members that are not base tables,
but even if it doesn't it certainly might some day. Furthermore, the
term "constraint exclusion" is a well-established. We're not going to
reduce confusing by adding a new feature with a similar name and
simultaneously renaming the old feature to something different. If
we're going to rename anything, it should be the new feature, though
I'm not entirely convinced that's really necessary either.

...Robert

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2009-12-08 03:05:27 Re: EXPLAIN BUFFERS
Previous Message Itagaki Takahiro 2009-12-08 02:58:57 Re: EXPLAIN BUFFERS