From: Jim C. Nasby <jnasby@pervasive.com>
To: Richard Huxton <dev@archonet.com>
Cc: David Lang <david@lang.hm>
Cc: Joost Kraaijeveld <J.Kraaijeveld@Askesis.nl>
Cc: pgsql-performance@postgresql.org
Subject: Re: x206-x225
Date: Tue, 14 Mar 2006 16:08:18 -0600
Message-ID: <20060314220817.GA45250@pervasive.com> (raw)
In-Reply-To: <4417379D.9020801@archonet.com>
References: <GMEAJIDMNDKCIHMMHDFLCEKHDHAA.hjs@rmax.nl>
<441181C6.3040401@archonet.com>
<1142063378.6634.13.camel@localhost>
<Pine.LNX.4.62.0603102355550.23148@qnivq.ynat.uz>
<20060314203253.GT45250@pervasive.com>
<4417379D.9020801@archonet.com>
On Tue, Mar 14, 2006 at 09:37:33PM +0000, Richard Huxton wrote:
> >But shouldn't it be possible to batch up WAL writes and syncs? In other
> >words, if you have 5 transactions that all COMMIT at exactly the same
> >time, it should be possible to get all 5 WAL pages (I'll assume each
> >one generated a small enough change so as not to require multiple WAL
> >pages) to the drive before the platter comes around to the right
> >position. The drive should then be able to write all 5 at once. At
> >least, theoretically...
>
> I think you mean this...
>
> http://www.postgresql.org/docs/8.1/static/runtime-config-wal.html
>
> commit_delay (integer)
No, that's not what I mean at all. On a system doing a large number of
WAL-generating transactions per second, it's certainly possible for
multiple transactions to commit in the period of time it takes for the
platter to rotate back into position to allow for writing of the WAL
data. What I don't know is if those multiple transactions would actually
make it to the platter on that rotation, or if they'd serialize,
resulting in one commit per revolution. I do know that there's no
theoretical reason that they couldn't, it's just a matter of putting
enough intelligence in the drive.
Perhaps this is something that SCSI supports and (S)ATA doesn't, since
SCSI allows multiple transactions to be 'in flight' on the bus at once.
But since you mention commit_delay, this does lead to an interesting
possible use: set it equal to the effective rotational period of the
drive. If you know your transaction load well enough, you could possibly
gain some benefit here. But of course a RAID controller with a BBU would
be a better bet...
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
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: jnasby@pervasive.com, dev@archonet.com, david@lang.hm, J.Kraaijeveld@Askesis.nl
Subject: Re: x206-x225
In-Reply-To: <20060314220817.GA45250@pervasive.com>
* 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