| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Bruce Momjian <bruce(at)momjian(dot)us> |
| Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: PG 14 release notes, first draft |
| Date: | 2021-05-11 20:47:32 |
| Message-ID: | CAH2-Wz=aonqHWgEKf-c+2PDy71_quWhFKxQa5N+iBiTBqM2rCg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, May 11, 2021 at 1:41 PM Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > "Allow VACUUM to eagerly place newly deleted B-Tree pages in the Free
> > Space Map. Previously VACUUM could only place preexisting deleted
> > pages in the Free Space Map for recycling."
>
> So, previously it could only place pages that were deleted from the
> previous vacuum on the free list?
Yes, exactly -- that's how it worked, even though in general there was
no way to predict when the next VACUUM would be. Now VACUUM will
usually manage to do everything in the same VACUUM operation, starting
from deleting the index tuples that make the page empty, then deleting
the page, and finally putting the page in the FSM. Makes a big
difference when the workload has lots of page deletions, say due to
range deletions.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2021-05-11 20:57:01 | Re: Printing backtrace of postgres processes |
| Previous Message | Bruce Momjian | 2021-05-11 20:41:19 | Re: PG 14 release notes, first draft |