Simon Riggs <simon(at)2ndQuadrant(dot)com> wrote:
> This patch extends that and actually sets the tuple header flag as
> HEAP_XMIN_COMMITTED during the load.
So, without bulk-load conditions, a long-lived tuple in PostgreSQL
is written to disk at least five times:
(1) The WAL record for the inserted tuple is written.
(2) The inserted tuple is written.
(3) The HEAP_XMIN_COMMITTED bit is set and the tuple is re-written
in place some time after the inserting transaction's COMMIT.
(4) The WAL record for the "freeze" in write 5 is written.
(5) The xmin is set to frozen and the tuple is rewritten in place
some time after every other connection can see it.
Prior to your patch, bulk load omitted write 1. With your patch we
will also omit write 3.
Since you've just been looking at this area, do you have any
thoughts about writes 4 and 5 being rendered unnecessary by writing
bulk-loaded tuples with a frozen xmin, and having transactions with
a snapshot which doesn't include the bulk load's transaction just
not seeing the table? (Or am I just dreaming about those?)
 If you are archiving, it could be more.
In response to
pgsql-hackers by date
|Next:||From: Simon Riggs||Date: 2012-02-25 18:58:12|
|Subject: Re: COPY with hints, rebirth|
|Previous:||From: Kevin Grittner||Date: 2012-02-25 18:06:38|
|Subject: Re: foreign key locks, 2nd attempt|