On Fri, Jan 2, 2009 at 11:13 PM, Robert Haas <robertmhaas(at)gmail(dot)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-184.108.40.206-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.
In response to
pgsql-hackers by date
|Next:||From: Robert Haas||Date: 2009-01-03 04:34:11|
|Subject: Re: Significantly larger toast tables on 8.4?|
|Previous:||From: Gregory Stark||Date: 2009-01-03 04:15:10|
|Subject: Re: posix_fadvise v22|