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 |
Cc: | Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>, Paul Jungwirth <pj(at)illuminatedcomputing(dot)com> |
Subject: | Re: Exclusion constraints on partitioned tables |
Date: | 2023-01-24 14:38:13 |
Message-ID: | 10212835.nUPlyArG6x@aivenlaptop |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Le vendredi 16 décembre 2022, 06:11:49 CET Paul Jungwirth a écrit :
> On 12/15/22 16:12, Tom Lane wrote:
> >> This patch also requires the matching constraint columns to use equality
> >> comparisons (`(foo WITH =)`), so it is really equivalent to the existing
> >> b-tree rule.
> >
> > That's not quite good enough: you'd better enforce that it's the same
> > equality operator (and same collation, if relevant) as is being used
> > in the partition key.
> > [snip]
> > It might work better to consider the operator itself and ask if
> > it's equality in the same btree opfamily that's used by the
> > partition key.
>
> Thank you for taking a look! Here is a comparison on just the operator
> itself.
>
I've taken a look at the patch, and I'm not sure why you keep the restriction
on the Gist operator being of the RTEqualStrategyNumber strategy. I don't
think we have any other place where we expect those strategy numbers to
match. For hash it's different, as the hash-equality is the only operator
strategy and as such there is no other way to look at it. Can't we just
enforce partition_operator == exclusion_operator without adding the
RTEqualStrategyNumber for the opfamily into the mix ?
From | Date | Subject | |
---|---|---|---|
Next Message | Bharath Rupireddy | 2023-01-24 14:46:18 | Re: Improve GetConfigOptionValues function |
Previous Message | Hayato Kuroda (Fujitsu) | 2023-01-24 14:34:05 | RE: Perform streaming logical transactions by background workers and parallel apply |