On 21 January 2013 13:10, Noah Misch 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 you yourself had
On 19 January 2013 20:38, Noah Misch 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
easily viewable
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 changes
On 16 November 2012 01:20, Stephen Frost 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 breakthroughs. There was
* 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 a
On 15 November 2012 08:56, Greg Smith 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 that that can make
On 15 November 2012 10:04, Magnus Hagander 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
On Thu, Nov 15, 2012 at 9:56 AM, Greg Smith 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 has valid
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 fo
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 optimist
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 r
> -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
>
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 related
to commit_delay still sa
13 matches
Mail list logo
