Re: Slow select performance despite seemingly reasonable query plan
От | David Brain |
---|---|
Тема | Re: Slow select performance despite seemingly reasonable query plan |
Дата | |
Msg-id | 849c74160905070811o1c512c1esd452870a153eea52@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Slow select performance despite seemingly reasonable query plan (Matthew Wakeling <matthew@flymine.org>) |
Ответы |
Re: Slow select performance despite seemingly reasonable
query plan
Re: Slow select performance despite seemingly reasonable query plan |
Список | 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 по дате отправления: