From: | "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru> |
---|---|
To: | Melanie Plageman <melanieplageman(at)gmail(dot)com> |
Cc: | Pgsql Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: CF entries for 17 to be reviewed |
Date: | 2024-03-06 13:49:48 |
Message-ID: | 2AFAACF9-27F2-4433-B62D-DC825DD7BA11@yandex-team.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On 4 Mar 2024, at 14:51, Andrey M. Borodin <x4mmm(at)yandex-team(dot)ru> wrote:
>
> I’ve read other small sections.
Here are statuses for "Refactoring" section:
* New [relation] options engine
Relatively heavy refactoring. Author keeps interest to the patch for some years now. As I understood the main problem is that big refactoring cannot be split into incremental steps. Definitely worth reviewing, but I think not for 17 already...
* Confine vacuum skip logic to lazy_scan_skip
There was a discussion at the end of 2023, but no recent review activity. Author actively improves the patchset.
* Change prefetch and read strategies to use range in pg_prewarm
Some discussion is happening. Changed to WoA to reflect actual status.
* Potential issue in ecpg-informix decimal converting functions
On Daniel's TODO list.
* BitmapHeapScan table AM violation removal (and use streaming read API)
Active discussion with reviewers is going on.
* Streaming read sequential and TID range scan
Seems like discussion on this patch is going on in nearby threads. In this thread I observe only improved patch versions posted.
All in all "Refactoring" section seemed to me more complex and demanding in-depth knowledge. It's difficult to judge why new approaches are an improvement. So for newcomer reviewers I'd recommend to look to other sections.
Thanks.
Best regards, Andrey Borodin.
From | Date | Subject | |
---|---|---|---|
Next Message | Bharath Rupireddy | 2024-03-06 14:02:28 | Re: Add new error_action COPY ON_ERROR "log" |
Previous Message | Laurenz Albe | 2024-03-06 13:32:06 | Re: Wrong security context for deferred triggers? |