Re: posix_fadvise v22 - Mailing list pgsql-hackers

From Greg Stark
Subject Re: posix_fadvise v22
Date
Msg-id 4136ffa0901022026yfe11975yb45575259f796a39@mail.gmail.com
Whole thread Raw
In response to Re: posix_fadvise v22  ("Robert Haas" <robertmhaas@gmail.com>)
List pgsql-hackers
On Fri, Jan 2, 2009 at 11:13 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> When I did that, it when back from 50 s to 33 s, which I think means
> that posix_fadvise is getting called and that that is what is making
> it slower.
>
>> And is this on a system with multiple spindles? How many?
>
> Latitude D830 laptop.  Single disk.  Fedora 9.  kernel-2.6.27.9-73.fc9.x86_64.
>
>> And how much of the data is in shared buffers or in filesystem cache?
>> Is this consistent for repeated queries? Is it only when you're
>> repeating a query for dates that you've already selected?
>
> I stopped the cluster, dropped the page cache, and restarted the
> cluster just before testing.  Repeated tests are fast due to caching
> effects.  shared_buffers is 240MB.  System has 2GB RAM, steady state
> is about 1GB of page cache.

Ahhh. So this is a test of how much impact the extra syscalls and
buffer lookups have on a system where they're not really helping. I'm
still surprised, a 50% performance penalty is a lot worse than I would
have expected, especially when the buffers aren't in cache. I did one
quick test and saw about 10% performance penalty in that test.

-- 
greg


pgsql-hackers by date:

Previous
From: Gregory Stark
Date:
Subject: Re: posix_fadvise v22
Next
From: "Robert Haas"
Date:
Subject: Re: Significantly larger toast tables on 8.4?