Jim C. Nasby wrote:
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 transaction
On Tue, Mar 14, 2006 at 09:37:33PM +, 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 generate
Jim C. Nasby wrote:
On Fri, Mar 10, 2006 at 11:57:16PM -0800, David Lang wrote:
On Sat, 11 Mar 2006, Joost Kraaijeveld wrote:
On Fri, 2006-03-10 at 13:40 +, Richard Huxton wrote:
Your ATA disk is lying about disk caching being turned off. Assuming
each insert is in a separate transaction,
On Fri, Mar 10, 2006 at 11:57:16PM -0800, David Lang wrote:
> On Sat, 11 Mar 2006, Joost Kraaijeveld wrote:
>
> >On Fri, 2006-03-10 at 13:40 +, Richard Huxton wrote:
> >>Your ATA disk is lying about disk caching being turned off. Assuming
> >>each insert is in a separate transaction, then it's
On Sat, 11 Mar 2006, Joost Kraaijeveld wrote:
Date: Sat, 11 Mar 2006 09:17:09 +0100
From: Joost Kraaijeveld <[EMAIL PROTECTED]>
To: David Lang <[EMAIL PROTECTED]>
Cc: Richard Huxton , pgsql-performance@postgresql.org
Subject: Re: [PERFORM] x206-x225
On Fri, 2006-03-10 at 23:57
On Sat, 2006-03-11 at 11:59 -0500, Tom Lane wrote:
> Joost Kraaijeveld <[EMAIL PROTECTED]> writes:
> > I assume that for PostgreSQL "written to disk" is after fsync returned
> > successfully. In practice that could very well mean that the data is
> > still in a cache somewhere (controller or harddi
Joost Kraaijeveld <[EMAIL PROTECTED]> writes:
> I assume that for PostgreSQL "written to disk" is after fsync returned
> successfully. In practice that could very well mean that the data is
> still in a cache somewhere (controller or harddisk, not in the OS
> anymore, see also man page of fsync)
W
On Sat, 2006-03-11 at 12:33 +0100, PFC wrote:
> >> each transaction requires a sync to the disk, a sync requires a real
> >> write (which you then wait for), so you can only do one transaction per
> >> rotation.
> > Not according to a conversation I had with Western Digital about the
>
>
> It dep
each transaction requires a sync to the disk, a sync requires a real
write (which you then wait for), so you can only do one transaction per
rotation.
Not according to a conversation I had with Western Digital about the
It depends if you consider that "written to the disk" means "data is
s
On Fri, 2006-03-10 at 23:57 -0800, David Lang wrote:
> On Sat, 11 Mar 2006, Joost Kraaijeveld wrote:
>
> > On Fri, 2006-03-10 at 13:40 +, Richard Huxton wrote:
> >> Your ATA disk is lying about disk caching being turned off. Assuming
> >> each insert is in a separate transaction, then it's not
On Sat, 11 Mar 2006, Joost Kraaijeveld wrote:
On Fri, 2006-03-10 at 13:40 +, Richard Huxton wrote:
Your ATA disk is lying about disk caching being turned off. Assuming
each insert is in a separate transaction, then it's not going to do
10,000 / 6 = 1667 transactions/sec - that's faster than
On Fri, 2006-03-10 at 13:40 +, Richard Huxton wrote:
> Your ATA disk is lying about disk caching being turned off. Assuming
> each insert is in a separate transaction, then it's not going to do
> 10,000 / 6 = 1667 transactions/sec - that's faster than it's rotational
> speed.
Could you expla
The primary slow down is probably between your system bus from main
memory to your disk storage. If you notice from your statistics that
the select statements are very close. This is because all the data you
need is already in system memory. The primary bottle neck is probably
disk I/O. Scsi will a
H.J. Sanders wrote:
X206 IBM X226
-----
processorPentium 4 3.2
GhzXeon 3.0 Ghz
main memory1.25
GB
Hello list.
We have compared 2 IBM x
servers:
IBM
X206
IBM X226
--
---
processor
Pentium 4 3.
15 matches
Mail list logo
