Re: CommitDelay performance improvement - Mailing list pgsql-hackers

From Philip Warner
Subject Re: CommitDelay performance improvement
Date
Msg-id 3.0.5.32.20010224145412.03240ba0@mail.rhyme.com.au
Whole thread Raw
In response to Re: CommitDelay performance improvement  (ncm@zembu.com (Nathan Myers))
Responses Re: CommitDelay performance improvement  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
At 14:57 23/02/01 -0800, Nathan Myers wrote:
>
>When thinking about tuning N, I like to consider what are the interesting 
>possible values for N:
>

It may have been much earler in the debate, but has anyone checked to see
what the maximum possible gains might be - or is it self-evident to people
who know the code?

Would it be worth considering creating a test case with no flush in
RecordTransactionCommit, and rely on checkpointing to flush? I realize this
is never an option in production, but is it possible to modify the code in
this way? I *should* give an upper limit on the gains that can be made by
flushing at the best possible time.


----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.B.N. 75 008 659 498)          |          /(@)   ______---_
Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 0500 83 82 82         |                 ___________ |
Http://www.rhyme.com.au          |                /           \|                                |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/


pgsql-hackers by date:

Previous
From: "Diehl, Jeffrey"
Date:
Subject: RE: [SQL] handling of database size exceeding physical disk space
Next
From: Peter Eisentraut
Date:
Subject: RE: beta5 ...