Horton

Re: post-freeze damage control

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alexander Korotkov <aekorotkov@gmail.com>
Cc: Peter Geoghegan <pg@bowt.ie>, Robert Haas <robertmhaas@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2024-04-09T20:42:14Z
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. revert: Transform OR clauses to ANY expression

  2. Fix incorrect calculation in BlockRefTableEntryGetBlocks.

Alexander Korotkov <aekorotkov@gmail.com> writes:
> On Tue, Apr 9, 2024 at 7:27 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Yeah, that's one of the reasons I'm dubious that the committed
>> patch was ready.

> While inventing this GUC, I was thinking more about avoiding
> regressions rather than about unleashing the full power of this
> optimization.  But now I see that that wasn't good enough.  And it was
> definitely hasty to commit to this shape.  I apologize for this.

> Tom, I think you are way more experienced in this codebase than me.
> And, probably more importantly, more experienced in making decisions
> for planner development.  If you see some way forward to polish this
> post-commit, Andrei and I are ready to work hard on this with you.  If
> you don't see (or don't think that's good), let's revert this.

It wasn't ready to commit, and I think trying to fix it up post
feature freeze isn't appropriate project management.  Let's revert
it and work on it more in the v18 time frame.

			regards, tom lane