| From: | Melanie Plageman <melanieplageman(at)gmail(dot)com> |
|---|---|
| To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
| 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:28:49 |
| Message-ID: | CAAKRu_aBthDxatwzR-wQ8bWfYehuxYgAO0g6AMPFyVgdOxfS4g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Sun, Sep 1, 2024 at 6:00 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
>
> On Sun, Sep 1, 2024 at 5:44 PM Pavel Luzanov <p(dot)luzanov(at)postgrespro(dot)ru> wrote:
> > I see a perfectly working TID-store optimization.
> > With reduced maintenance_work_mem it used only one 'vacuuming indexes'
> > phase instead of 21 in v16.
> > But I also expected to see a reduction in the number of WAL records
> > and the total size of the WAL. Instead, WAL numbers have significantly
> > degraded.
> >
> > What am I doing wrong?
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.
- Melanie
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2024-09-02 17:47:28 | Re: PG17 optimizations to vacuum |
| Previous Message | veem v | 2024-09-02 16:09:06 | Re: Partitioning and unique key |