From: Craig Ringer <craig@postnewspapers.com.au>
To: pgsql-performance@postgresql.org
Subject: Re: How filesystems matter with PostgreSQL
Date: Sun, 06 Jun 2010 15:48:19 +0800
Message-ID: <4C0B52C3.4050901@postnewspapers.com.au> (raw)
In-Reply-To: <4C0B455C.8050902@cheapcomplexdevices.com>
References: <4C08EEDF.7090403@mtu.net>
<4C0AD180.90607@2ndquadrant.com>
<4C0AD280.5020105@mtu.net>
<4C0AD547.2040308@2ndquadrant.com>
<4C0AD7DF.1030705@mtu.net>
<4C0B455C.8050902@cheapcomplexdevices.com>
On 06/06/10 14:51, Ron Mayer wrote:
> Jon Schewe wrote:
>
>> OK, so if I want the 15 minute speed, I need to give up safety (OK in
>> this case as this is just research testing), or see if I can tune
>> postgres better.
>
> Depending on your app, one more possibility would be to see if you
> can re-factor the application so it can do multiple writes in parallel
> rather than waiting for each one to complete. If I understand right,
> then many transactions could potentially be handled by a single fsync.
By using a commit delay, yes. (see postgresql.conf). You do open up the
risk of losing transactions committed within the commit delay period,
but you don't risk corruption like you do with fsync.
Sometimes you can also batch work into bigger transactions. The classic
example here is the usual long stream of individual auto-committed
INSERTs, which when wrapped in an explicit transaction can be vastly
quicker.
--
Craig Ringer
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: craig@postnewspapers.com.au
Subject: Re: How filesystems matter with PostgreSQL
In-Reply-To: <4C0B52C3.4050901@postnewspapers.com.au>
* 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