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

From Laurent Wandrebeck
Subject Re: Slow select performance despite seemingly reasonable query plan
Date
Msg-id fc593b510905090243u6ff7412bw4a8a8b89c7df461d@mail.gmail.com
Whole thread Raw
In response to Re: Slow select performance despite seemingly reasonable query plan  (David Brain <dbrain@bandwidth.com>)
List pgsql-performance
2009/5/7 David Brain <dbrain@bandwidth.com>:
> Hi,
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.
default rhel ext3 options are (in 4.x and 5.x) :
Filesystem features:      has_journal ext_attr resize_inode dir_index
filetype needs_recovery sparse_super large_file
See tune2fs -l /dev/sdXY
Laurent.

pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: Bad Plan for Questionnaire-Type Query
Next
From: David Blewett
Date:
Subject: Re: Bad Plan for Questionnaire-Type Query