Re: Exclusion constraints on partitioned tables

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Paul A Jungwirth <pj(at)illuminatedcomputing(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Ronan Dunklau <ronan(dot)dunklau(at)aiven(dot)io>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Exclusion constraints on partitioned tables
Date: 2023-07-12 07:34:42
Message-ID: b2a08477-aa90-ed2b-d783-3d86d1c6be8d@eisentraut.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 11.07.23 07:52, Paul A Jungwirth wrote:
> On Mon, Jul 10, 2023 at 8:06 AM Paul A Jungwirth
> <pj(at)illuminatedcomputing(dot)com> wrote:
>>
>> On Mon, Jul 10, 2023 at 7:05 AM Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>>> I'm not sure what value we would get from testing this with btree_gist,
>>> but if we wanted to do that, then adding a new test file to the
>>> btree_gist sql/ directory would seem reasonable to me.
>>>
>>> (I would make the test a little bit bigger than you had shown, like
>>> insert a few values.)
>>>
>>> If you want to do that, please send another patch. Otherwise, I'm ok to
>>> commit this one.
>>
>> I can get you a patch tonight or tomorrow. I think it's worth it since
>> btree_gist uses different strategy numbers than ordinary gist.
>
> Patch attached.

Looks good, committed.

I had some second thoughts about the use of get_attname(). It seems the
previous code used the dominant style of extracting the attribute name
from the open relation handle, so I kept it that way. That's also more
efficient than going via the syscache.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Gurjeet Singh 2023-07-12 07:42:14 Better help output for pgbench -I init_steps
Previous Message suyu.cmj 2023-07-12 07:20:57 Re: The same 2PC data maybe recovered twice