On Tue, Aug 2, 2011 at 8:34 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> Our docs suggest an optimization to reduce WAL logging when you are
> creating and populating a table:
> In minimal level, WAL-logging of some bulk operations, like CREATE
> INDEX, CLUSTER and COPY on a table that was created or truncated in the
> same transaction can be safely skipped, which can make those operations
> much faster (see Section 14.4.7). But minimal WAL does not contain
> enough information to reconstruct the data from a base backup and the
> WAL logs, so either archive or hot_standby level must be used to enable
> WAL archiving (archive_mode) and streaming replication.
> I am confused why we issue significant WAL traffic for CREATE INDEX?
> Isn't the index either created or removed if the transaction fails?
> What crash recovery activity state do we need WAL logging for? I
> realize we have to do WAL logging for streaming replication, but CREATE
> TABLE isn't going to affect that. I also realize the index has to be
> on disk on commit, but the same is true for doing the CREATE TABLE in
> the same transaction block.
> Does this optimization work for INSERT ... SELECT?
I don't think so -- insert/select doesn't take a full table lock and
it writes to the heap. The optimization only works when other
backends will never see/touch the data being written out until it is
finished and it doesn't matter if the data is scrambled due to a
crash. CREATE INDEX might work though.
In response to
pgsql-hackers by date
|Next:||From: Heikki Linnakangas||Date: 2011-08-02 14:27:13|
|Subject: Re: WAL logging volume and CREATE TABLE|
|Previous:||From: Bruce Momjian||Date: 2011-08-02 13:34:56|
|Subject: WAL logging volume and CREATE TABLE|