Re: odd postgresql performance (excessive lseek)

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: odd postgresql performance (excessive lseek)
Дата
Msg-id AANLkTikPgyZtWs-hR2aEbX6Bs_Qxe-c9ACv268ozgMOq@mail.gmail.com
обсуждение исходный текст
Ответ на Re: odd postgresql performance (excessive lseek)  (Greg Smith <greg@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Greg Smith
Дата:
Сообщение: Re: odd postgresql performance (excessive lseek)
Следующее
От: "Ozer, Pam"
Дата:
Сообщение: Slow Query- Simple taking