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
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 |