From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
Cc: | Peter Geoghegan <pg(at)bowt(dot)ie>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: post-freeze damage control |
Date: | 2024-04-09 20:42:14 |
Message-ID: | 3868476.1712695334@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alexander Korotkov <aekorotkov(at)gmail(dot)com> writes:
> On Tue, Apr 9, 2024 at 7:27 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Korotkov | 2024-04-09 20:48:12 | Re: post-freeze damage control |
Previous Message | Tom Lane | 2024-04-09 20:37:31 | Re: post-freeze damage control |