From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
Cc: | Amit Langote <amitlangote09(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: PG 18 release notes draft committed |
Date: | 2025-05-06 19:44:16 |
Message-ID: | aBpmkAFdfPeo8IAH@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, May 6, 2025 at 03:14:56PM +1200, David Rowley wrote:
> On Tue, 6 May 2025 at 03:59, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> >
> > On Mon, May 5, 2025 at 09:42:10PM +1200, David Rowley wrote:
> > > I agree that 88f55bc97 and d69d45a5a should be in their own item.
> > > Likely no need to go into detail about the speed up being about
> > > "EquivalenceClass lookups". I imagine something like "Reduce planner
> > > overheads when planning queries to partitioned and inheritance parent
> > > tables"
> > >
> > > Then for bb3ec16e1, d47cbf474, cbc127917 and 525392d57, something like
> > > "Defer locking of partitions during execution until after partition
> > > elimination". The release notes for 11.0 called it "partition
> > > elimination", so I went with that naming.
> >
> > Okay, I split them up and went with the attached patch.
>
>
> > +Allow partitions to be pruned more efficienty (Ashutosh Bapat, Yuya Watari, David Rowley)
>
> I think you've misunderstood what's been changed here. Unfortunately,
> it's not even true with a bit of eye squinting as these changes have
> nothing to do with partition pruning. I think it would be much more
I think what you are saying is that this has to do with partition
processing of joins, but not the pruning process. I don't think a
non-partition joins are likely to hit 32 EquivalenceClasses.
> informative to state it as I suggested. Also, the spelling of
> "efficiently" needs adjusted.
Fixed. My spell check filter was wrong.
> > +Avoid the locking of pruned partitions during planning (Amit Langote)
>
> At the very least, you'd need to swap "planning" for "execution" as
> the above statement isn't true.
I went with the attached patch.
--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com
Do not let urgent matters crowd out time for investment in the future.
Attachment | Content-Type | Size |
---|---|---|
master.diff | text/x-diff | 973 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Sami Imseih | 2025-05-06 20:01:32 | Re: queryId constant squashing does not support prepared statements |
Previous Message | Dmitry Dolgov | 2025-05-06 19:42:10 | Re: queryId constant squashing does not support prepared statements |