Re: [GENERAL] WAL - Mailing list pgsql-general

From Albe Laurenz
Subject Re: [GENERAL] WAL
Date
Msg-id A737B7A37273E048B164557ADEF4A58B539A4867@ntex2010i.host.magwien.gv.at
Whole thread Raw
In response to [GENERAL] WAL  (Torsten Förtsch <tfoertsch123@gmail.com>)
Responses Re: [GENERAL] WAL
List pgsql-general
Torsten Förtsch wrote:
> if I do something like this:
> 
> BEGIN;
> UPDATE tbl SET data='something' WHERE pkey='selector';
> UPDATE tbl SET data=NULL WHERE pkey='selector';
> COMMIT;
> 
> Given 'selector' actually exists, I get a separate WAL entry for each of the updates. My question is,
> does the first update actually hit the data file?

It should, yes.

> If I am only interested in the first update hitting the WAL, does it make sense to do something like
> the above in a transaction? Would that help to keep the table small in a high concurrency situation?
> The table itself has a small fillfactor. So, in most cases there should be enough space to do a HOT
> update. For that HOT update, is that second update setting data to NULL beneficial or rather adverse?

How could the second update *not* be WAL logged?

Maybe you could explain what you are trying to achieve.

Yours,
Laurenz Albe

pgsql-general by date:

Previous
From: "t.dalpozzo@gmail.com"
Date:
Subject: Re: [GENERAL] huge table occupation after updates
Next
From: Torsten Förtsch
Date:
Subject: Re: [GENERAL] WAL