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
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 |