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

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Reply via email to