On Tue, Aug 2, 2011 at 8:34 AM, Bruce Momjian <br...@momjian.us> wrote: > Our docs suggest an optimization to reduce WAL logging when you are > creating and populating a table: > > > http://www.postgresql.org/docs/9.0/static/runtime-config-wal.html#RUNTIME-CONFIG-WAL-SETTINGS > > 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. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
