Hi,
Martijn van Oosterhout wrote:
>> The executor would have to be clever enough to not do a single index
>> scan, but possibly scan through multiple indexes when asking for
>> uniqueness, depending on the partitioning rule set.
>
> But it's not the executor that checks uniqueness, it's built into the
> btre code.
Well, it's the executor calling into the btree code. Couldn't the
executor choose which (btree-) indexes to query for uniqueness?
> If someone manages to crack uniqueness for GiST indexes, we'll have our
> answer, since it has exactly the same problem but on a different scale.
> (Or vice-versa, if some gets uniqueness for multiple indexes, we can do
> it for GiST also).
Uh.. can you elaborate on that? AFAICS, you would simply have to query
multiple btree indexes and make sure non of them is violated. How would
that help making unique GiST indexes possible? What's the problem there?
Regards
Markus