From: Tom Lane <tgl@sss.pgh.pa.us>
To: jay <jackem.mojx@alibaba-inc.com>
Cc: 'Heikki Linnakangas' <heikki@enterprisedb.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: 答复: [PERFORM] Postgresql update op is very very slow
Date: Thu, 26 Jun 2008 11:04:21 -0400
Message-ID: <16213.1214492661@sss.pgh.pa.us> (raw)
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>
"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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, jackem.mojx@alibaba-inc.com, heikki@enterprisedb.com
Subject: Re: 答复: [PERFORM] Postgresql update op is very very slow
In-Reply-To: <16213.1214492661@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox