From: | Ronan Dunklau <ronan(dot)dunklau(at)aiven(dot)io> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Paul Jungwirth <pj(at)illuminatedcomputing(dot)com> |
Cc: | Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Exclusion constraints on partitioned tables |
Date: | 2023-03-20 08:24:59 |
Message-ID: | 4467897.LvFx2qVVIh@aivenlaptop |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Le vendredi 17 mars 2023, 17:03:09 CET Paul Jungwirth a écrit :
> I added the code about RTEqualStrategyNumber because that's what we need
> to find an equals operator when the index is GiST (except if it's using
> an opclass from btree_gist; then it needs to be BTEqual again). But then
> I realized that for exclusion constraints we have already figured out
> the operator (in RelationGetExclusionInfo) and put it in
> indexInfo->ii_ExclusionOps. So we can just compare against that. This
> works whether your index uses btree_gist or not.
>
> Here is an updated patch with that change (also rebased).
Thanks ! This looks fine to me like this.
>
> I also included a more specific error message. If we find a matching
> column in the index but with the wrong operator, we should say so, and
> not say there is no matching column.
>
I agree that's a nicer improvement.
Regards,
--
Ronan Dunklau
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2023-03-20 08:32:17 | Re: Memory leak from ExecutorState context? |
Previous Message | Tomas Vondra | 2023-03-20 08:19:41 | Re: logical decoding and replication of sequences, take 2 |