Skip site navigation (1) Skip section navigation (2)

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

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,Martijn van Oosterhout <kleptog(at)svana(dot)org>,Greg Stark <gsstark(at)mit(dot)edu>, Rod Taylor <pg(at)rbt(dot)ca>,Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [Bizgres-general] WAL bypass for INSERT, UPDATE and
Date: 2006-01-04 00:11:55
Message-ID: 1136333515.5052.273.camel@localhost.localdomain (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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. 

Best Regards, Simon Riggs

In response to


pgsql-hackers by date

Next:From: Josh BerkusDate: 2006-01-04 01:16:19
Subject: Re: [Bizgres-general] WAL bypass for INSERT, UPDATE and
Previous:From: Simon RiggsDate: 2006-01-03 23:58:09
Subject: Re: [Bizgres-general] WAL bypass for INSERT, UPDATE and

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group