Re: Slow select performance despite seemingly reasonable query plan - Mailing list pgsql-performance

From David Brain
Subject Re: Slow select performance despite seemingly reasonable query plan
Date
Msg-id 849c74160905070811o1c512c1esd452870a153eea52@mail.gmail.com
Whole thread Raw
In response to Re: Slow select performance despite seemingly reasonable query plan  (Matthew Wakeling <matthew@flymine.org>)
Responses Re: Slow select performance despite seemingly reasonable query plan  (Matthew Wakeling <matthew@flymine.org>)
Re: Slow select performance despite seemingly reasonable query plan  (Laurent Wandrebeck <l.wandrebeck@gmail.com>)
List pgsql-performance
Hi,

Some answers in-line:

>
> Has there been a performance *change*, or are you just concerned about a
> query which doesn't seem to use "enough" disc bandwidth?

Performance has degraded noticeably over the past few days.

> Certainly random access like this index scan can be extremely slow. 2-4 MB/s
> is quite reasonable if you're fetching one 8kB block per disc seek - no more
> than 200 per second.

We have read ahead set pretty aggressively high as the SAN seems to
'like' this, given some testing we did:

/sbin/blockdev --getra /dev/sdb
16384


> One concern I might have with a big setup like that is how big the database
> directory has got, and whether directory lookups are taking time. Check to
> see if you have the directory_index option enabled on your ext3 filesystem.
>

That's a thought, I doubt the option is set (I didn't set it and I
don't _think_ rhel does by default), however the 'base' directory only
contains ~5500 items total, so it's not getting too out of hand.

David

pgsql-performance by date:

Previous
From: Matthew Wakeling
Date:
Subject: Re: Slow select performance despite seemingly reasonable query plan
Next
From: Nikolas Everett
Date:
Subject: Re: Slow select performance despite seemingly reasonable query plan