Re: Horrific time for getting 1 record from an index?

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: Horrific time for getting 1 record from an index?
Дата
Msg-id CAHyXU0yE+RUSTJ4PPteqG9q5KPSu1ZQZDW2qzPJq_P+y008ZEA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Horrific time for getting 1 record from an index?  (Jim Nasby <jnasby@enova.com>)
Список pgsql-performance
On Tue, Nov 12, 2013 at 6:22 PM, Jim Nasby <jnasby@enova.com> wrote:
> On 11/12/13 6:17 PM, Jeff Janes wrote:
>>
>> I verified that this is the case--the empty pages remain linked in the
>> tree until a vacuum removes them.  But walking through empty leaf pages is
>> way faster than resolving pages full of pointers to dead-to-all tuple, so
>> the kill code still gives a huge benefit.  But of course nothing will do
>> much good until the transaction horizon advances.
>
>
> Aaaand... that gets to the other problem... our SAN performance is pretty
> abysmal. It took ~270 seconds to read 80MB of index pages (+ whatever heap)
> to get to the first live tuple. (This was run close enough to the vacuum
> that I don't think visibility of these tuples would have changed
> mid-stream).

That's awful, but 'par for the course' for SANs in my experience.  If
my math is right, that works out to 27ms / page read.   But each index
page read can cause multiple heap page reads depending on how the data
is organized so I think you are up against the laws of physics.   All
we can do is to try and organize data so that access patterns are less
radom and/or invest in modern hardware.

merlin


В списке pgsql-performance по дате отправления:

Предыдущее
От: Marc Mamin
Дата:
Сообщение: CREATE TABLE AS WITH FREEZE ?
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: Performance bug in prepared statement binding in 9.2?