Re: Patch: Global Unique Index

From: Cary Huang <cary(dot)huang(at)highgo(dot)ca>
To: "Thomas Kellerer" <shammat(at)gmx(dot)net>
Cc: "pgsql-hackers" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Patch: Global Unique Index
Date: 2022-11-24 18:15:39
Message-ID: 184aada3c76.1258dc67d3231678.3658037825540104775@highgo.ca
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

---- On Thu, 24 Nov 2022 08:00:59 -0700 Thomas Kellerer wrote ---
> Pavel Stehule schrieb am 24.11.2022 um 07:03:
> > There are many Oracle users that find global indexes useful despite
> > their disadvantages.
> >
> > I have seen this mostly when the goal was to get the benefits of
> > partition pruning at runtime which turned the full table scan (=Seq Scan)
> > on huge tables to partition scans on much smaller partitions.
> > Partition wise joins were also helpful for query performance.
> > The substantially slower drop partition performance was accepted in thos cases
> >
> >
> > I think it would be nice to have the option in Postgres as well.
> >
> > I do agree however, that the global index should not be created automatically.
> >
> > Something like CREATE GLOBAL [UNIQUE] INDEX ... would be a lot better
> >
> >
> > Is it necessary to use special marks like GLOBAL if this index will
> > be partitioned, and uniqueness will be ensured by repeated
> > evaluations?
> >
> > Or you think so there should be really forced one relation based
> > index?
> >
> > I can imagine a unique index on partitions without a special mark,
> > that will be partitioned, and a second variant classic index created
> > over a partitioned table, that will be marked as GLOBAL.
>
>
> My personal opinion is, that a global index should never be created
> automatically.
>
> The user should consciously decide on using a feature
> that might have a serious impact on performance in some areas.

Agreed, if a unique index is created on non-partition key columns without including the special mark (partition key columns), it may be a mistake from user. (At least I make this mistake all the time). Current PG will give you a warning to include the partition keys, which is good.

If we were to automatically turn that into a global unique index, user may be using the feature without knowing and experiencing some performance impacts (to account for extra uniqueness check in all partitions).

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2022-11-24 18:23:59 Re: Fix for visibility check on 14.5 fails on tpcc with high concurrency
Previous Message Ankit Kumar Pandey 2022-11-24 17:57:11 Re: Questions regarding distinct operation implementation