Re: [Bizgres-general] WAL bypass for INSERT, UPDATE and

Bruce Momjian <pgman@candle.pha.pa.us>

From: Bruce Momjian <pgman@candle.pha.pa.us>
To: Simon Riggs <simon@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Martijn van Oosterhout <kleptog@svana.org>, Greg Stark <gsstark@mit.edu>, Rod Taylor <pg@rbt.ca>, Qingqing Zhou <zhouqq@cs.toronto.edu>, pgsql-hackers@postgresql.org
Date: 2006-01-05T17:27:05Z
Lists: pgsql-hackers
Simon Riggs wrote:
> On Thu, 2005-12-29 at 11:37 -0500, Bruce Momjian wrote:
> > Having COPY behave differently because it is
> > in a transaction is fine as long as it is user-invisible, but once you
> > require users to do that to get the speedup, it isn't user-invisible
> > anymore.
> 
> Since we're agreed on adding ALTER TABLE rather than COPY LOCK, we have
> our explicit mechanism for speedup.
> 
> However, it costs a single line of code and very very little execution
> time to add in the optimization to COPY to make it bypass WAL when
> executed in the same transaction that created the table. Everything else
> is already there.
> 
> As part of the use_wal test:
> + 	if (resultRelInfo->ri_NumIndices == 0 && 
> +         !XLogArchivingActive()            &&
> >>         (cstate->rel->rd_createSubid != InvalidSubTransactionId ))
> +             use_wal = false;
> 
> the value is already retrieved from cache...
> 
> Can anyone see a reason *not* to put that change in also? We just don't
> advertise it as the "suggested" route to gaining performance, nor would
> we rely on it for pg_dump/restore performance. 

Seems like a nice optimization.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073