From: | Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at> |
---|---|
To: | 'Torsten Förtsch *EXTERN*' <tfoertsch123(at)gmail(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: WAL |
Date: | 2016-12-12 11:37:33 |
Message-ID: | A737B7A37273E048B164557ADEF4A58B539A4867@ntex2010i.host.magwien.gv.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Torsten Förtsch | 2016-12-12 12:23:58 | Re: WAL |
Previous Message | t.dalpozzo@gmail.com | 2016-12-12 09:07:35 | Re: huge table occupation after updates |