On 21 January 2013 13:10, Noah Misch n...@leadboat.com wrote:
What filesystem did you use for testing? Would you also provide /proc/cpuinfo
or a rough description of the system's CPUs?
Unfortunately, I don't have access to that server at the moment. It's
under Greg Smith's control. I believe
On 19 January 2013 20:38, Noah Misch n...@leadboat.com wrote:
staticloud.com seems to be gone. Would you repost these?
I've pushed these to a git repo, hosted on github.
https://github.com/petergeoghegan/commit_delay_benchmarks
I'm sorry that I didn't take the time to make the html benchmarks
I've added this to the open commitfest. I think that a formal review
is probably required here.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Peter Geoghegan wrote:
Some of you will be aware that I've tried to formulate a good general
recommendation for setting the value of commit_delay, in light of the
improvements made in 9.3. I previously asked for help finding a
methodology for optimising commit_delay [1]. The documentation
On 11/15/12 12:19 AM, Albe Laurenz wrote:
If there is an agreement that half the sync time as reported by
pg_test_fsync is a good value, would it make sense to have initdb test
sync time and preset commit_delay?
Peter has validated this against a good range of systems, but it would
be
On 11/15/2012 04:56 PM, Greg Smith wrote:
I would rather see this just turn into one of the things a more
general tuning tool knew how to do, executing against a fully setup
system. Having a useful implementation of commit_delay and useful docs
on it seems like enough of a jump forward for
On Thu, Nov 15, 2012 at 9:56 AM, Greg Smith g...@2ndquadrant.com wrote:
On 11/15/12 12:19 AM, Albe Laurenz wrote:
If there is an agreement that half the sync time as reported by
pg_test_fsync is a good value, would it make sense to have initdb test
sync time and preset commit_delay?
Peter
On 15 November 2012 10:04, Magnus Hagander mag...@hagander.net wrote:
I would rather see this just turn into one of the things a more general
tuning tool knew how to do, executing against a fully setup system. Having a
useful implementation of commit_delay and useful docs on it seems like
On 15 November 2012 08:56, Greg Smith g...@2ndquadrant.com wrote:
My main concern with this would be the relatively common practice of moving
the pg_xlog directory after initdb time.
I probably should have increased the default number of seconds that
pg_test_fsync runs for, in light of the fact
* Peter Geoghegan (pe...@2ndquadrant.com) wrote:
I am inclined to agree. I did attempt to use the instrumentation
macros to have commit_delay set adaptively at runtime, which would
have at least addressed this concern, but that just didn't work as
well as this.
Setting it at run-time was
On 16 November 2012 01:20, Stephen Frost sfr...@snowman.net wrote:
Setting it at run-time was actually my first thought on this. I'm
disappointed to hear that it didn't work out well.
I actually did quite a lot of research on it, that was interesting,
but ultimately didn't lead to any
-Original Message-
From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
ow...@postgresql.org] On Behalf Of Peter Geoghegan
Sent: 15 November 2012 09:44
To: PG Hackers
Subject: [HACKERS] Doc patch making firm recommendation for setting the
value of commit_delay
Some of
12 matches
Mail list logo
