Re: Proposal: Global Index for PostgreSQL

From: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
To: Amit Langote <amitlangote09(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Nikita Malakhov <hukutoc(at)gmail(dot)com>, wenhui qiu <qiuwenhuifx(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Proposal: Global Index for PostgreSQL
Date: 2025-07-11 11:17:27
Message-ID: CAFiTN-tBZTzdGYvRj0EaYkBXHKe1L6Hmza9Csb_s4B0F6EFc9g@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jul 11, 2025 at 12:22 PM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:

> Thanks, I see that you've thought this through and opted for the safe
> route of locking all possible partitions during planning, both for
> SELECT and INSERT.
>
> That seems like the only viable option today, given how the executor
> assumes that each index scan targets a single heap relation which has
> already been opened and locked before execution begins. But even so, I
> think we should not assume locking is cheap. Even with improvements
> like fast-path locking or a higher max_locks_per_transaction, locking
> thousands of partitions still adds up. This can become noticeable even
> in regular query execution, since one of the motivations for global
> indexes is to reduce planning effort, for example by avoiding
> per-partition scan node generation. In such cases, the relative cost
> of locking can become a dominant part of query startup time.

That's right

> I do not have a better solution right now, but it is worth keeping
> this tradeoff in mind.

I agree. Thanks for your opinion on this.

--
Regards,
Dilip Kumar
Google

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Eduard Stefes 2025-07-11 12:01:29 Re: [V2] Adding new CRC32C implementation for IBM S390X
Previous Message Nikita Malakhov 2025-07-11 11:03:42 Re: Some ExecSeqScan optimizations