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
