On Mon, 14 Sep 2020 at 06:03, Laurenz Albe <laurenz.albe@xxxxxxxxxxx> wrote: > These are probably the "hint bits" set on newly committed rows by the first reader. > Note that te blocks are dirtied during the sequential scan, not during the update. > > You could try VACUUMing the tables before the update (which will set hint bits) > and see if you still get the dirtied blocks. Thanks. I thought about that as well, but unfortunately VACUUMing does not seem to solve this. Even a full VACUUM does not prevent the dirty blocks, and even very old/never updated but often read tables see this behaviour. In my sample, the plain update w/ suppress_redundant_updates_trigger() does cause the dirty blocks, but if I do an update that compares the fields, like this: update testtable as d set name = s.name from testtable_temp as s where d.id = s.id and d.name <> s.name; then no blocks are dirtied. So it seems suppress_redundant_updates_trigger() does not entirely avoid writing _something_ to the blocks, and I don't know what it is and how to avoid it. I would of course like to avoid having to specify every column in the where clause. Kind regards, Mike (sorry Laurenz, forgot to include the list in my initial reply)
