Skip site navigation (1) Skip section navigation (2)

Re: crash-safe visibility map, take three

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Jeff Davis" <pgsql(at)j-davis(dot)com>
Cc: "Heikki Linnakangas" <heikki(dot)linnakangas(at)enterprisedb(dot)com>, "Bruce Momjian" <bruce(at)momjian(dot)us>, <pgsql-hackers(at)postgresql(dot)org>,"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: crash-safe visibility map, take three
Date: 2010-12-02 19:16:09
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> And, if we had a bulk loading path, we could probably get away
> with writing the data only twice (today, we write it 3 times
> including the hint bits) or maybe once if WAL archiving is off.
If you're counting WAL writes, you're low.  If you don't go out of
your way to avoid it, you are likely to write the data to the table
once during the bulk load, a second time on first read to set the
hint bits, and a third time to freeze data to prevent wrap-around. 
The initial write may or may not be WAL-logged.  The freezing
typically is WAL-logged.
So, you can easily write the data to disk four or five times.  With
luck these are spread out uniformly or happen during off-peak
periods.  Unmanaged, a WAL-logged freeze of bulk-loaded data is
somewhat more likely to occur, however, during hours of heavy OLTP
load, because transaction numbers are consumed so quickly.
Currently, a VACUUM FREEZE after a bulk load collapses at least two
of those writes to one.  With luck, some pages might still be dirty
in cache, and you can save two of the writes.

In response to

pgsql-hackers by date

Next:From: Greg StarkDate: 2010-12-02 19:24:13
Subject: Re: Spread checkpoint sync
Previous:From: Joachim WielandDate: 2010-12-02 19:13:13
Subject: Re: WIP patch for parallel pg_dump

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group