pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Greg Stark <stark@enterprisedb.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Greg Smith <gsmith@gregsmith.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>
Cc: Postgres <pgsql-hackers@postgresql.org>
Subject: Re: posix_fadvise v22
Date: Fri, 2 Jan 2009 23:26:41 -0500
Message-ID: <4136ffa0901022026yfe11975yb45575259f796a39@mail.gmail.com> (raw)
In-Reply-To: <603c8f070901022013u242179fbq4ba97e2f5aea3715@mail.gmail.com>
References: <FDDBA24E-FF4D-4654-BA75-692B3BA71B97@enterprisedb.com>
	<603c8f070901011230t1afa6644racb715b975078054@mail.gmail.com>
	<10658.1230843315@sss.pgh.pa.us>
	<603c8f070901011843p121e40afu35c4a7bdc51c051c@mail.gmail.com>
	<Pine.GSO.4.64.0901020335150.16680@westnet.com>
	<603c8f070901021436v71f10188g1d747b493c89f2f5@mail.gmail.com>
	<4136ffa0901021502w78f0611dx63929ac0fbbdc2f4@mail.gmail.com>
	<603c8f070901021742s61dcbaf2r51deff1219196944@mail.gmail.com>
	<4136ffa0901021902m3d9565e8v6d62a75c4a81511a@mail.gmail.com>
	<603c8f070901022013u242179fbq4ba97e2f5aea3715@mail.gmail.com>

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



view thread (41+ messages)  latest in thread

Message-ID: <4136ffa0901022026yfe11975yb45575259f796a39@mail.gmail.com>
Permalink:  ../4136ffa0901022026yfe11975yb45575259f796a39@mail.gmail.com/
Also on:    postgresql.org/message-id/4136ffa0901022026yfe11975yb45575259f796a39@mail.gmail.com

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: stark@enterprisedb.com, robertmhaas@gmail.com, gsmith@gregsmith.com, tgl@sss.pgh.pa.us, itagaki.takahiro@oss.ntt.co.jp
  Subject: Re: posix_fadvise v22
  In-Reply-To: <4136ffa0901022026yfe11975yb45575259f796a39@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox