| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Melanie Plageman <melanieplageman(at)gmail(dot)com> |
| Cc: | Pavel Luzanov <p(dot)luzanov(at)postgrespro(dot)ru>, "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
| Subject: | Re: PG17 optimizations to vacuum |
| Date: | 2024-09-02 17:47:28 |
| Message-ID: | CAH2-Wznqbnc8en8+B26obp-pmTKXi_HS_h_yRt4HVtqLOCKxLQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Mon, Sep 2, 2024 at 1:29 PM Melanie Plageman
<melanieplageman(at)gmail(dot)com> wrote:
> I'll investigate more tomorrow, but based on my initial investigation,
> there appears to be some interaction related to how much of the
> relation is in shared buffers after creating the table and updating
> it. If you set shared_buffers sufficiently high and prewarm the table
> after the update, master has fewer WAL records reported by vacuum
> verbose.
Fewer of what specific kind of WAL record?
All of the details about useful work done by VACUUM were identical
across versions. It was only the details related to WAL, buffers, and
CPU time that changed.
Perhaps I'm not thinking of something obvious. Maybe it's extra
VISIBILITY records? But I'd expect the number of VISIBILITY records to
match the number of pages frozen, given these particulars. VACUUM
VERBOSE at least shows that that hasn't changed.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Melanie Plageman | 2024-09-02 19:23:13 | Re: PG17 optimizations to vacuum |
| Previous Message | Melanie Plageman | 2024-09-02 17:28:49 | Re: PG17 optimizations to vacuum |