Re: Slow select performance despite seemingly reasonable query plan

From: David Brain <dbrain(at)bandwidth(dot)com>
To: Matthew Wakeling <matthew(at)flymine(dot)org>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Slow select performance despite seemingly reasonable query plan
Date: 2009-05-07 15:11:45
Message-ID: 849c74160905070811o1c512c1esd452870a153eea52@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Nikolas Everett 2009-05-07 15:18:03 Re: Slow select performance despite seemingly reasonable query plan
Previous Message Matthew Wakeling 2009-05-07 14:53:00 Re: Slow select performance despite seemingly reasonable query plan