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  (Matthew Wakeling <matthew@flymine.org>)
Re: Slow select performance despite seemingly reasonable query plan  (Laurent Wandrebeck <l.wandrebeck@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Matthew Wakeling
Дата:
Сообщение: Re: Slow select performance despite seemingly reasonable query plan
Следующее
От: Nikolas Everett
Дата:
Сообщение: Re: Slow select performance despite seemingly reasonable query plan