On Fri, Jul 11, 2025 at 12:22 PM Amit Langote 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
Hi Dilip,
Sorry for the late reply.
On Thu, Jul 3, 2025 at 1:24 PM Dilip Kumar wrote:
>
> On Wed, Jul 2, 2025 at 7:18 PM Amit Langote wrote:
>
> > Just to clarify -- I was hoping that, at least for SELECTs, we
> > wouldn’t need to lock all leaf partitions up front.
> >
> > One of the potential
On Wed, Jul 2, 2025 at 7:18 PM Amit Langote wrote:
> Just to clarify -- I was hoping that, at least for SELECTs, we
> wouldn’t need to lock all leaf partitions up front.
>
> One of the potential selling points of global indexes (compared to
> partitioned indexes) is that we can avoid expand_parti
On Wed, Jul 2, 2025 at 1:04 PM Dilip Kumar wrote:
> On Tue, Jul 1, 2025 at 7:12 PM Amit Langote wrote:
> > I’ve been working on improving how we handle partition locking during
> > execution of generic plans. Specifically, I committed a patch to defer
> > locking of partitions until after pruning
On Tue, Jul 1, 2025 at 7:12 PM Amit Langote wrote:
>
> Hi Dilip,
>
> Happy to see you working on this. It’s clear a lot of thought has
> gone into the design.
Thanks, Amit. And thanks for your comment.
> On Tue, Jul 1, 2025 at 6:27 PM Dilip Kumar wrote:
> > 6) Need to perform a performance t
Hi Dilip,
Happy to see you working on this. It’s clear a lot of thought has
gone into the design.
On Tue, Jul 1, 2025 at 6:27 PM Dilip Kumar wrote:
> 6) Need to perform a performance test, for SELECT/UPDATE/INSERT cases,
> we already know the VACUUM performance.
One point I want to check my un
On Wed, Jun 18, 2025 at 4:38 AM Masahiko Sawada wrote:
>
> On Sat, Jun 14, 2025 at 2:32 AM Dilip Kumar wrote:
> >
Thanks for your opinion, Sawada-San.
> Does it need to keep holding dead TIDs for each partition until it
> completes vacuuming all partitions that are covered by the global
> index
On Sat, Jun 14, 2025 at 2:32 AM Dilip Kumar wrote:
>
> On Mon, Jun 9, 2025 at 3:28 PM Dilip Kumar wrote:
> >
> > On Mon, Jun 9, 2025 at 2:03 PM Nikita Malakhov wrote:
>
> > > 4) Update-heavy partitioned tables that should run vacuum frequently.
> > > Significant
> > > vacuum slowdown would resu
On Mon, Jun 9, 2025 at 3:28 PM Dilip Kumar wrote:
>
> On Mon, Jun 9, 2025 at 2:03 PM Nikita Malakhov wrote:
> > 4) Update-heavy partitioned tables that should run vacuum frequently.
> > Significant
> > vacuum slowdown would result in going beyond SLAs without corresponding
> > significant impro
On Wed, Jun 11, 2025 at 1:08 AM Bruce Momjian wrote:
>
> On Mon, Jun 9, 2025 at 05:51:25PM -0400, Bruce Momjian wrote:
> > On Mon, Jun 9, 2025 at 03:28:38PM +0530, Dilip Kumar wrote:
> > There are certainly use cases where this would be helpful, but I think
> > the big question is whether it wou
On Tue, Jun 10, 2025 at 3:21 AM Bruce Momjian wrote:
Thanks Bruce for your thoughts on this.
> On Mon, Jun 9, 2025 at 03:28:38PM +0530, Dilip Kumar wrote:
> > On Mon, Jun 9, 2025 at 2:03 PM Nikita Malakhov wrote:
> > > Global Indexes is a very interesting functionality that has both
> > > sig
On Mon, Jun 9, 2025 at 05:51:25PM -0400, Bruce Momjian wrote:
> On Mon, Jun 9, 2025 at 03:28:38PM +0530, Dilip Kumar wrote:
> There are certainly use cases where this would be helpful, but I think
> the big question is whether it would have so many negatives that most
> people who try to use it w
On Mon, Jun 9, 2025 at 03:28:38PM +0530, Dilip Kumar wrote:
> On Mon, Jun 9, 2025 at 2:03 PM Nikita Malakhov wrote:
> > Global Indexes is a very interesting functionality that has both
> > significant advantages
> > and drawbacks, and the community seems not ready to accept it without very
> >
On Mon, Jun 9, 2025 at 2:03 PM Nikita Malakhov wrote:
>
> Hi Dilip!
Thanks Nikita for your response and reading my proposal.
> Global Indexes is a very interesting functionality that has both significant
> advantages
> and drawbacks, and the community seems not ready to accept it without very
Hi Dilip!
Global Indexes is a very interesting functionality that has both
significant advantages
and drawbacks, and the community seems not ready to accept it without very
strong
motivation.
There was a more recent approach to Global index problem [1], please check
it out.
I've read you proposal
On Fri, Jun 6, 2025 at 1:01 PM wenhui qiu wrote:
>
> Hi Dilip Kumar
>Thank you for your working on this ,I remember six years ago there was
> talk about global index ，You can see if this mailing list has any references
> to
> (https://www.postgresql.org/message-id/CALtqXTcurqy1PKXzP9XO%3Dof
Hi Dilip Kumar
Thank you for your working on this ,I remember six years ago there was
talk about global index ，You can see if this mailing list has any
references to (
https://www.postgresql.org/message-id/CALtqXTcurqy1PKXzP9XO%3DofLLA5wBSo77BnUnYVEZpmcA3V0ag%40mail.gmail.com
)
Thanks
On Fri
PostgreSQL’s table partitioning allows large tables to be broken into
smaller, more manageable pieces for better performance. However, a key
limitation currently is the absence of global indexes, which restricts
using partitioned tables, especially when you need unique constraints
on columns that a
18 matches
Mail list logo
