On Fri, Jan 2, 2009 at 11:13 PM, Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
