Re: odd postgresql performance (excessive lseek) - Mailing list pgsql-performance

From Merlin Moncure
Subject Re: odd postgresql performance (excessive lseek)
Date
Msg-id AANLkTikPgyZtWs-hR2aEbX6Bs_Qxe-c9ACv268ozgMOq@mail.gmail.com
Whole thread Raw
In response to Re: odd postgresql performance (excessive lseek)  (Greg Smith <greg@2ndquadrant.com>)
List pgsql-performance
On Tue, Oct 19, 2010 at 12:28 PM, Greg Smith <greg@2ndquadrant.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

pgsql-performance by date:

Previous
From: Greg Smith
Date:
Subject: Re: odd postgresql performance (excessive lseek)
Next
From: "Ozer, Pam"
Date:
Subject: Slow Query- Simple taking