| 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: | Whole Thread | Raw Message | 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 |