Skip site navigation (1) Skip section navigation (2)

Re: posix_fadvise v22

From: "Greg Stark" <stark(at)enterprisedb(dot)com>
To: "Robert Haas" <robertmhaas(at)gmail(dot)com>
Cc: "Greg Smith" <gsmith(at)gregsmith(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "ITAGAKI Takahiro" <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, Postgres <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: posix_fadvise v22
Date: 2009-01-03 04:26:41
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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-
>> 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 HaasDate: 2009-01-03 04:34:11
Subject: Re: Significantly larger toast tables on 8.4?
Previous:From: Gregory StarkDate: 2009-01-03 04:15:10
Subject: Re: posix_fadvise v22

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group