| 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: | Whole Thread | Raw Message | 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? |