Re: Slow select performance despite seemingly reasonable query plan

Поиск
Список
Период
Сортировка
От Scott Mead
Тема Re: Slow select performance despite seemingly reasonable query plan
Дата
Msg-id d3ab2ec80905070726w6173e495h4486cc96c8dda8d4@mail.gmail.com
обсуждение исходный текст
Ответ на Slow select performance despite seemingly reasonable query plan  (David Brain <dbrain@bandwidth.com>)
Ответы Re: Slow select performance despite seemingly reasonable query plan  (David Brain <dbrain@bandwidth.com>)
Список pgsql-performance
On Thu, May 7, 2009 at 10:14 AM, David Brain <dbrain@bandwidth.com> wrote:
Hi,

Some context, we have a _lot_ of data, > 1TB, mostly in 1 'table' -
the 'datatable' in the example below although in order to improve
performance this table is partitioned (by date range) into a number of
partition tables.  Each partition contains up to 20GB of data (tens of
millons of rows), with an additional ~3GB of indexes, all this is
served off a fairly high performance server (8 core 32Gb, with FC
attached SAN storage).  PostgreSQL version is 8.3.5 (running on 64bit
RHEL 5.2)

This has been working reasonably well, however in the last few days
I've been seeing extremely slow performance on what are essentially
fairly simple 'index hitting' selects on this data.  

   Have you re-indexed any of your partitioned tables?  If you're index is fragmented, you'll be incurring extra I/O's per index access.  Take a look at the pgstattuple contrib for some functions to determine index fragmentation.  You can also take a look at the pg_stat_all_indexes tables.  If your number of tup's fetched is 100 x more than your idx_scans, you *may* consider reindexing.

--Scott

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

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