Horton

Re: Proposal: Global Index for PostgreSQL

Dilip Kumar <dilipbalaut@gmail.com>

View thread
From: Dilip Kumar <dilipbalaut@gmail.com>
To: Amit Langote <amitlangote09@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>, Nikita Malakhov <hukutoc@gmail.com>, wenhui qiu <qiuwenhuifx@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-07-11T11:17:27Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. xml2: Improve error handling of libxml2 calls

On Fri, Jul 11, 2025 at 12:22 PM Amit Langote <amitlangote09@gmail.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