To: "jay" <jackem.mojx@alibaba-inc.com>
cc: "'Heikki Linnakangas'" <heikki@enterprisedb.com>,
	pgsql-performance@postgresql.org
Subject: Re:
 =?gb2312?B?tPC4tDogW1BFUkZPUk1dIFBvc3RncmVzcWwgdXBkYXRlIG9wIGlzIA==?=
	=?gb2312?B?dmVyeSB2ZXJ5IHNsb3c=?=
In-reply-to: <005101c8d773$ff81b2c0$0644000a@hz.ali.com> 
References: <473587.97248.qm@web32701.mail.mud.yahoo.com>
	<op.uc83c7m2cigqcu@apollo13.peufeu.com>
	<004b01c8d671$3dec1630$0544000a@hz.ali.com>
	<486219B6.7050003@enterprisedb.com>
	<005101c8d773$ff81b2c0$0644000a@hz.ali.com>
Comments: In-reply-to "jay" <jackem.mojx@alibaba-inc.com>
	message dated "Thu, 26 Jun 2008 18:04:18 +0800"
Date: Thu, 26 Jun 2008 11:04:21 -0400
Message-ID: <16213.1214492661@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"jay" <jackem.mojx@alibaba-inc.com> writes:
> 	I know the problem, because there are about 35 million rows , which
> cost about 12G disk space and checkpoint segments use 64, but update
> operation is in one transaction which lead fast fill up the checkpoint
> segments and lead do checkpoints frequently, but checkpoints will cost lots
> resources, so update operation become slowly and slowly and bgwrite won't
> write because it's not commit yet.
> Create a new table maybe a quick solution, but it's not appropriated in some
> cases.
> 	If we can do commit very 1000 row per round, it may resolve the
> problem.

No, that's utterly unrelated.  Transaction boundaries have nothing to do
with checkpoints.

			regards, tom lane