From: | Torsten Förtsch <tfoertsch123(at)gmail(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | WAL |
Date: | 2016-12-12 08:53:08 |
Message-ID: | CAKkG4_nthwDp+uyJJx_dbGXc7dV5TuR8p-Ff3rV62O2-FJ89Lg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hi,
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?
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?
Thanks,
Torsten
From | Date | Subject | |
---|---|---|---|
Next Message | t.dalpozzo@gmail.com | 2016-12-12 09:07:35 | Re: huge table occupation after updates |
Previous Message | Chris Withers | 2016-12-12 07:34:46 | Re: btree gist indices, null and open-ended tsranges |