| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Melanie Plageman <melanieplageman(at)gmail(dot)com> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Peter Geoghegan <pg(at)bowt(dot)ie>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de> |
| Subject: | Re: Emit fewer vacuum records by reaping removable tuples during pruning |
| Date: | 2024-01-09 19:33:29 |
| Message-ID: | CA+TgmobZ1bTqMMRGb2uKiYfVEx92sraHMwm7zHDZgyjQHGJpGg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Jan 9, 2024 at 2:23 PM Melanie Plageman
<melanieplageman(at)gmail(dot)com> wrote:
> Yes, I agree. I thought about it more, and I prefer updating the FSM
> and setting nonempty_pages into lazy_scan_[no]prune(). Originally, I
> had ordered the patch set with that first (before the patch to do
> immediate reaping), but there is no reason for it to be so. Using
> hastup can be done in a subsequent commit on top of the immediate
> reaping patch. I will post a new version of the immediate reaping
> patch which addresses your feedback. Then, separately, I will post a
> revised version of the lazy_scan_heap() refactoring patches.
I kind of liked it first, because I thought we could just do it and
get it out of the way, but if Andres doesn't agree with the idea, it
probably does make sense to push it later, as you say here.
--
Robert Haas
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2024-01-09 19:35:36 | Re: Emit fewer vacuum records by reaping removable tuples during pruning |
| Previous Message | Melanie Plageman | 2024-01-09 19:23:24 | Re: Emit fewer vacuum records by reaping removable tuples during pruning |