Re: Understanding WAL - large amount of activity from removing data

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Isaac Morland <isaac(dot)morland(at)gmail(dot)com>
Cc: PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Understanding WAL - large amount of activity from removing data
Date: 2022-11-21 02:02:12
Message-ID: CAKFQuwY6nKw38LT7bsyiZ-db7+ALbSO1gKc-vFWC7BL_zYqxwQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Nov 20, 2022 at 6:24 PM Isaac Morland <isaac(dot)morland(at)gmail(dot)com>
wrote:

> What I'm finding is that the UPDATE is taking over an hour for 5000
> records, and tons of WAL is being generated, several files per minute.
> Selecting the non-PDF columns from the entire table takes a few
> milliseconds, and the only thing I'm doing with the records is updating
> them to much smaller values. Why so much activity just to remove data? The
> new rows are tiny.
>

Simplistic answer (partly because the second part of this isn't spelled out
explicitly in the docs that I could find) when you UPDATE two things
happen, the old record is modified to indicate it has been deleted and a
new record is inserted. Both of these are written to the WAL, and a record
is always written to the WAL as a self-contained unit, so the old record is
full sized in the newly written WAL. TOAST apparently has an optimization
if you don't change the TOASTed value, but here you are so that
optimization doesn't apply.

David J.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2022-11-21 02:20:00 Re: when the startup process doesn't (logging startup delays)
Previous Message Isaac Morland 2022-11-21 01:24:11 Understanding WAL - large amount of activity from removing data