On Wed, Oct 30, 2019 at 9:23 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > Well, the *effects* of the feature seem desirable, but that doesn't > mean that we want an implementation that actually has a shared index. > As soon as you do that, you've thrown away most of the benefits of > having a partitioned data structure in the first place.
Right, but that's only the case for the global index. Global indexes are useful when used judiciously. They enable the use of partitioning for use cases where not being able to enforce uniqueness across all partitions happens to be a deal breaker. I bet that this is fairly common. > No, I don't have an idea how we might support, eg, uniqueness of > non-partition-key columns without that. But we need to spend our > effort on figuring that out, not on building a complicated mechanism > whose performance is never going to not suck. I don't think that there is a way to solve the problem that doesn't look very much like a global index. Also, being able to push down a partition number when scanning a global index seems like it would be very compelling in some scenarios. I'm a bit worried about the complexity that will need to be added to nbtree to make global indexes work, but it's probably possible to come up with something that isn't too bad. GIN already uses an implementation level attribute number column for multi-column GIN indexes, which is a little like what Ibrar has in mind. The really complicated new code required for global indexes will be in places like vacuumlazy.c. -- Peter Geoghegan
