From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Torsten Förtsch <tfoertsch123(at)gmail(dot)com> |
Cc: | PostgreSQL mailing lists <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Exclusion constraint with negated operator? |
Date: | 2023-06-13 20:15:41 |
Message-ID: | 1799076.1686687341@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
=?UTF-8?Q?Torsten_F=C3=B6rtsch?= <tfoertsch123(at)gmail(dot)com> writes:
> My question is can I somehow express something like
> EXCLUDE (c1 WITH =, c2 with NOT =)
> It seems that's not possible at the moment. But is there any obstacle in
> principle or is it just not implemented?
Well, it'd likely be a bad idea. Indexes are meant to help you quickly
find a small part of a table that satisfies a condition. Finding the
probably-much-larger part of the table that doesn't satisfy the condition
is something they are bad at. This is why "=" is an indexable operator
while "<>" is not. It's not impossible in principle for "<>" to be an
index operator, but the set of cases where indexing on such a condition
would beat a seqscan is likely to be uselessly small. By the same
token, EXCLUDE constraints using such a condition would be unpleasantly
inefficient.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2023-06-13 21:56:42 | Re: Support logical replication of DDLs |
Previous Message | Patrick O'Toole | 2023-06-13 19:24:51 | Helping planner to chose sequential scan when it improves performance |