Re: odd postgresql performance (excessive lseek)

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Greg Smith <greg(at)2ndquadrant(dot)com>
Cc: Jon Nelson <jnelson+pgsql(at)jamponi(dot)net>, pgsql-performance(at)postgresql(dot)org
Subject: Re: odd postgresql performance (excessive lseek)
Date: 2010-10-19 17:41:04
Message-ID: AANLkTikPgyZtWs-hR2aEbX6Bs_Qxe-c9ACv268ozgMOq@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Tue, Oct 19, 2010 at 12:28 PM, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
> Jon Nelson wrote:
>>
>> That's a little harsh (it's not untrue, though).
>>
>
> Welcome to pgsql-performance!  You can get a right answer, or a nice answer,
> but given the personalities involved it's hard to get both at the same time.
>  With this crowd, you need to be careful stating something you were
> speculating about as if you were certain of it, and to be certain here
> usually means "I read the source code".  I recommend writing theories as a
> question ("would X have sped this up?") rather than a statement ("X will
> speed this up") if you want to see gentler answers.
>
>> Has any work been done on making use of shared memory for file stats
>> or using fallocate (or posix_fallocate) to allocate files in larger
>> chunks?
>>
>
> Just plain old pre-allocating in larger chunks turns out to work well.  Am
> hoping to get that into an official patch eventually.

hm...wouldn't larger allocation blocks reduce the frequency of 'this
file got larger via another backend' type events, and therefore raise
the benefit of pushing the events out vs checking them over and over?

merlin

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Ozer, Pam 2010-10-19 18:21:02 Slow Query- Simple taking
Previous Message Greg Smith 2010-10-19 16:28:29 Re: odd postgresql performance (excessive lseek)