LINUX.ORG.RU
Форум — Development  

PostgreSQL 8.2. Как сделать быстрее?


0

0 

Не могу разобраться с PostgreSQL (8.2). Есть таблица:

CREATE TABLE dict
(
  url_id integer NOT NULL,
  word text NOT NULL,
  intag integer NOT NULL
)
WITH (OIDS=FALSE);
ALTER TABLE dict OWNER TO user1;

CREATE INDEX dict_url
  ON dict
  USING btree
  (url_id);

CREATE INDEX dict_word
  ON dict
  USING btree
  (word);

CREATE INDEX dict_word_url_id
  ON dict
  USING btree
  (word, url_id);

Это стандартная таблица из mnogosearch. Длина поля word фактически не более 64 символов (точнее сейчас 32, но может быть и больше).

В postgresql.conf:
shared_buffers = 64MB # было 28M
work_mem = 16MB # было 1MB

Все это дело работает на FreeBSD 6.2-RELEASE
CPU: Intel(R) Core(TM)2 Duo CPU     E4500  @ 2.20GHz (2205.01-MHz 686-class CPU)
Mem: 183M Active, 1527M Inact, 181M Wired, 106M Cache, 112M Buf, 3816K Free
Swap: 512M Total, 304K Used, 512M Free

EXPLAIN SELECT COUNT(1) FROM dict;
Aggregate (cost=2325136.10..2325136.11 rows=1 width=0)
  ->  Seq Scan on dict (cost=0.00..2031228.08 rows=117283208 width=0)

SELECT * FROM dict WHERE word = 'someword';
Total query runtime: 103149 ms.
27844 rows retrieved.

Вопрос в том, что очень уж медленно. Как можно узнать почему и решить этот вопрос?
← разработка БД
Кому нечем занятся (Нужна простая Fuse FS) →
Ответ на: комментарий от AlexKiriukha

А действительно 117 млн. записей в таблице, Vacuum analyze делается регулярно?
А смена типов не поможет, в доке постгреса говорится, что text даже предпочтительнее.

There are no performance differences between these three types, apart from the increased storage size when using the blank-padded type. While character(n) has performance advantages in some other database systems, it has no such advantages in PostgreSQL. In most situations text or character varying should be used instead.

Можно глянуть vmstat,iostat посмотреть где он буксует на диске,памяти или cpu

Chumka ★★★
()
Ответ на: комментарий от Chumka

> А действительно 117 млн. записей в таблице, Vacuum analyze делается регулярно?

Перебор всех записей таблицы и после вакуума тормозить будет.

mv ★★★★★
()

вот это можешь пустить:

EXPLAIN ANALYZE SELECT * FROM dict WHERE word = 'someword';

Вообще очень странно. INDEX dict_word ON dict USING btree(word) есть, выбираем 27,844 / 117,283,208 < 1% записей... Тут любая дбмс индекс должна использовать...

gods-little-toy ★★★
()
Ответ на: комментарий от gods-little-toy

Гм, создание индекса не увидел ;) Возникает вопрос: а чем поможет btree поиску по текстовому полю? Здесь явно нужен хеш.

mv ★★★★★
()
Ответ на: комментарий от Chumka

> А действительно 117 млн. записей в таблице, Vacuum analyze делается регулярно?

Еще не делал. Только наполнил.

> А смена типов не поможет, в доке постгреса говорится, что text даже предпочтительнее.

На всякий случай сделал дамп и пытаюсь поменять тип. А вдруг? Поводу документации - читал, но что-то не припоминаю. Это как всегда - пока не столкнёшься - не упомнишь :-)

AlexKiriukha ★★★★
() автор топика
Ответ на: комментарий от AlexKiriukha

> Оно?

Да, оно, но btree использовать здесь неправильно. Т.к. запрос вида WHERE A=B, то хеш придётся очень кстати.

mv ★★★★★
()
Ответ на: комментарий от mv

> Возникает вопрос: а чем поможет btree поиску по текстовому полю? Здесь явно нужен хеш.

Хеш был бы быстрее наверно, но и BTREE должно помочь. В btree можно вполне эффективно заглянуть по значению 'someword'.

gods-little-toy ★★★
()
Ответ на: комментарий от AlexKiriukha

> Это как всегда - пока не столкнёшься - не упомнишь :-)

Если вкратце, то нужно сразу обращать внимание на сканирование таблицы при выполнении запроса :) На больших таблицах это эквивалентно тормозам.

mv ★★★★★
()
Ответ на: комментарий от gods-little-toy

> Хеш был бы быстрее наверно, но и BTREE должно помочь. В btree можно вполне эффективно заглянуть по значению 'someword'.

Как видно по explain, не помогло :)

mv ★★★★★
()
Ответ на: комментарий от mv

1. seq_scan до vacuum analyze и после него дают очень разные результаты
2. чтобы небыло seq_scan надо собрать статистику (это слово analyze делает :))

Chumka ★★★
()
Ответ на: комментарий от mv

> > Хеш был бы быстрее наверно, но и BTREE должно помочь. В btree можно вполне эффективно заглянуть по значению 'someword'.

> Как видно по explain, не помогло :)

аж сам попробовал... на моем примере - работает, но только после ANALYZE. А в MySQL кстати и без ANALYZE.

gods-little-toy ★★★
()
Ответ на: комментарий от gods-little-toy 

> EXPLAIN ANALYZE SELECT * FROM dict WHERE word = 'someword';

Bitmap Heap Scan on dict  (cost=726.24..100421.98 rows=29274 width=24) (actual time=102.586..54425.229 rows=27844 loops=1)
  Recheck Cond: (word = 'someword'::text)
  ->  Bitmap Index Scan on dict_word  (cost=0.00..718.92 rows=29274 width=0) (actual time=86.697..86.697 rows=27844 loops=1)
        Index Cond: (word = 'someword'::text)
Total runtime: 54484.578 ms

AlexKiriukha ★★★★
() автор топика

Преобразование text -> varchar отменил, так как по документации кажется бесполезным. Планы на ближайшее время:

Попробовать VACUUM ANALIZE по таблице dict

Попробовать INDEX USING hash

AlexKiriukha ★★★★
() автор топика
Ответ на: комментарий от AlexKiriukha

То есть это таки индекс. Лучше этого наврядли чего будет. Узкое место - скорее всего диск, но лучше бы это проверить... можешь пустить запрос, и посмотреть что "iostat -x /dev/where-database-is 1" будет показывать в столбце %util ?

gods-little-toy ★★★
()
Ответ на: комментарий от AlexKiriukha

> Попробовать VACUUM ANALIZE по таблице dict

99% что не поможет

> Попробовать INDEX USING hash

будет интересно узнать, сообщи о результатах. моя догадка - лучше не станет.

gods-little-toy ★★★
()
Ответ на: комментарий от AlexKiriukha

> Попробовать VACUUM ANALIZE по таблице dict

В районе pg8.0, помнится, бывало такое, что ломались индексы: pg упорно не хотел их использовать даже после vacuum analize. После переиндексации всё становилось на свои места.

mv ★★★★★
()
Ответ на: комментарий от gods-little-toy

>> Попробовать VACUUM ANALIZE по таблице dict

> 99% что не поможет

Не помогло :-)

>> Попробовать INDEX USING hash

> будет интересно узнать, сообщи о результатах. моя догадка - лучше не станет.

До сих пор жду. Что-то долго, но машина работает, а не я, так что можно и подождать ;-)

> iostat -x /dev/where-database-is 1

Как только доколбасит - проверю и выложу результаты.

AlexKiriukha ★★★★
() автор топика
Ответ на: комментарий от mv

Что ждать-то? Не будет там быстрее. Судя по приводимым количеству записей и времени, узкое место - шарение по диску когда оно записи достает. Как это фиксить не очень ясно.

- Завести кластерный индекс или partitioning, чтобы интересующие нас записи лежали рядом?

- Поставить кучу памяти, чтобы все было в кеше?

- Устроить какой-то большой редизайн всей базы чтобы эта большая таблица вообще исчезла?

gods-little-toy ★★★
()
Ответ на: комментарий от gods-little-toy

Пардонствую, но одно дело шариться по индексу, а другое - по таблице

mv ★★★★★
() 

Вобщем создавало по хешу оно трое суток, пришло озарение и попробовал то же, но на 10000 записей.

Изменения скорости не заметил. Интересно то, что если для запроса

SELECT url_id, intag WHERE word = 'someword';

раньше (при типе btree) использовался индекс dict_word, то после замены на hash, стал использоваться dict_word_url_id.

Вот соответствующие планы:
                               QUERY PLAN
-------------------------------------------------------------------------
 Bitmap Heap Scan on dict  (cost=4.64..72.56 rows=50 width=40)
   Recheck Cond: (word = 'senao'::text)
   ->  Bitmap Index Scan on dict_word  (cost=0.00..4.63 rows=50 width=0)
         Index Cond: (word = 'senao'::text)
(4 rows)

                                   QUERY PLAN
-------------------------------------------------------------------------------
-
 Bitmap Heap Scan on dict  (cost=4.64..72.56 rows=50 width=40)
   Recheck Cond: (word = 'senao'::text)
   ->  Bitmap Index Scan on dict_word_url_id  (cost=0.00..4.63 rows=50 width=0)
         Index Cond: (word = 'senao'::text)
(4 rows)

Завтра добавят RAM до 4GB, но думаю это не решение.

AlexKiriukha ★★★★
() автор топика
Ответ на: комментарий от AlexKiriukha

удалить индекс dict_word_url_id (или поменять в нем местами url_id, word) и посмтреть на результат... и вообще в первоначальном варианте при наличии индекса dict_word_url_id индекс dict_word был пожалуй лишним...

anonymous
() 

На данный момент увеличил working_mem до 64MB, эффекта не заметно.

[alex@localhost ~]$ iostat 1
      tty             ad4              ad6             cpu
 tin tout  KB/t tps  MB/s   KB/t tps  MB/s  us ni sy in id
   0   44 16.54   4  0.07  13.09   1  0.01   0  0  0  0 100
   0  174  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   2  0  9  0 89
   0   58  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00  16.00   8  0.12   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00  16.00   6  0.09   0  0  0  0 100
   0   59  0.00   0  0.00   4.67   3  0.01   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  1  0 99
   0   58  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
      tty             ad4              ad6             cpu
 tin tout  KB/t tps  MB/s   KB/t tps  MB/s  us ni sy in id
   0   59  0.00   0  0.00  16.00   1  0.01   0  0  0  0 100
   0  174  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00  16.00   1  0.01   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  2  0 97
   0   58  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59 16.00   3  0.04   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00  16.00   2  0.03   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
      tty             ad4              ad6             cpu
 tin tout  KB/t tps  MB/s   KB/t tps  MB/s  us ni sy in id
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0  174  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  1  0 98
   0   58  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00  16.00   1  0.02   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   1  0  2  0 98
   0   58  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00  16.00   1  0.01   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
      tty             ad4              ad6             cpu
 tin tout  KB/t tps  MB/s   KB/t tps  MB/s  us ni sy in id
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0  174  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  1  0 99
   0   58  0.00   0  0.00   0.00   0  0.00   0  0  0  0 99
   0   58  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59 16.00   1  0.01   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59 16.00   1  0.01   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   1  0  2  0 97
   0   58  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 99
   0   58  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
      tty             ad4              ad6             cpu
 tin tout  KB/t tps  MB/s   KB/t tps  MB/s  us ni sy in id
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0  174  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   1  0  0  0 99
   0   58  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   9.00   2  0.02   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   1  0  0  0 99
   0   58  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59 16.00   3  0.04   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
      tty             ad4              ad6             cpu
 tin tout  KB/t tps  MB/s   KB/t tps  MB/s  us ni sy in id
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0  174  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100

AlexKiriukha ★★★★
() автор топика
Ответ на: комментарий от AlexKiriukha 

[alex@localhost ~]$ vmstat 1
 procs      memory      page                    disks     faults      cpu
 r b w     avm    fre  flt  re  pi  po  fr  sr ad4 ad6   in   sy  cs us sy id
 0 0 0  149372 1543396   37   0   0   0  27   0   0   0  181  102 417  0  0 100
 0 0 0  149372 1543396    1   0   0   0   0   0   0   0  195  149 438  0  0 100
 0 0 0  149372 1543396    0   0   0   0   0   0   0   0  184  130 415  0  0 100
 0 0 0  149372 1543396    0   0   0   0   0   0   0   2  181  132 415  0  0 100
 0 0 0  149372 1543396    0   0   0   0   0   0   0   0  158  130 366  0  0 100
 0 0 0  149372 1543396    0   0   0   0   0   0   0   0  163  132 374  0  0 100
 0 0 0  149372 1543396    0   0   0   0   0   0   0   0  165  142 382  0  0 100
 0 0 0  151468 1542300  464   0   0   0   0   0   0   0  221 9650 518  1  4 95
 0 0 0  151468 1542300    0   0   0   0   0   0   0   0  196  146 437  0  0 100
 0 0 0  151468 1542300    0   0   0   0   0   0   0   0  179  144 409  0  0 100
 0 0 0  151468 1542300  323   0   0   0   4   0   0   2  204 2908 451  1  1 98
 0 0 0  151468 1542300    0   0   0   0   0   0   0   0  199  144 440  0  0 100
 0 0 0  151468 1542300    0   0   0   0   0   0   0   0  210  146 464  0  0 100
 0 0 0  151468 1542300    0   0   0   0   0   0   0   0  202  140 447  0  0 100
 0 0 0  151468 1542300    0   0   0   0   0   0   0   0  209  138 456  0  0 100
 0 0 0  151468 1542300    0   0   0   0   0   0   0   0  201  428 453  0  0 100
 0 0 0  151468 1542300    0   0   0   0   0   0   0   0  211  154 463  0  0 100
 0 0 0  151468 1542308    0   0   0   0   2   0   0   0  223 4482 481  0  2 97
 0 0 0  151468 1542308    0   0   0   0   0   0   0   0  202  146 446  0  0 100
 0 0 0  151468 1542308    0   0   0   0   0   0   0  10  210  141 473  0  0 100
 0 0 0  151468 1542308    0   0   0   0   0   0   0   0  199  142 441  0  0 100
 0 0 0  151468 1542308    0   0   0   0   0   0   0   0  204  152 455  0  0 100
 0 0 0  151468 1542308    0   0   0   0   0   0   0   0  209  566 466  0  0 100
 0 0 0  151468 1542308   12   0   0   0   0   0   0   0  221 3429 482  1  2 97
 0 0 0  151468 1542308    0   0   0   0   0   0   0   0  200  142 446  0  0 100
 0 0 0  151468 1542308    0   0   0   0   0   0   0   0  199  148 453  0  0 100
 0 0 0  151468 1542308    0   0   0   0   0   0   0   0  205  150 454  0  0 100
 0 0 0  151468 1542308    0   0   0   0   0   0   0   0  198  144 444  0  0 100
 0 0 0  151468 1542308    0   0   0   0   0   0   0   0  254 3069 539  1  1 98
 0 0 0  151468 1542308    0   0   0   0   0   0   0   0  206  153 459  0  0 100
 0 0 0  151468 1542308    0   0   0   0   0   0   0   0  205  146 453  0  0 100
 0 0 0  151468 1542308    0   0   0   0   0   0   0   0  198  156 445  0  0 100
 0 0 0  151468 1542308    0   0   0   0   0   0   0   0  197  146 440  0  0 100
 1 0 0  151468 1542308    0   0   0   0   0   0   0   0  228 1271 498  1  0 99
 0 0 0  151468 1542308    2   0   0   0   0   0   0   1  199 1909 452  0  0 100
 0 0 0  151468 1542308    0   0   0   0   0   0   0   0  188  148 424  0  0 100
 0 0 0  151468 1542308    0   0   0   0   0   0   0   0  185  154 420  0  0 100
 0 0 0  151468 1542308    0   0   0   0   0   0   0   0  189  148 428  0  0 100
 0 0 0  151468 1542308    0   0   0   0   0   0   0   0  195  142 430  0  0 100
 0 0 0  151468 1542308  197   0   0   0 169   0   0   0  197  684 461  0  0 100
 0 0 0  151468 1542308    0   0   0   0   0   0   0   0  206 4427 455  1  1 98
 0 0 0  151468 1542308    0   0   0   0   0   0   0   0  189  156 429  0  0 100
 0 0 0  151468 1542308    0   0   0   0   0   0   0   0  188  146 421  0  0 100
 0 0 0  151468 1542308    0   0   0   0   0   0   3   0  201  152 451  0  0 100
 0 0 0  151468 1542308    0   0   0   0   0   0   0   0  188  138 423  0  0 100
 0 0 0  151468 1542308    7   0   0   0   0   0   0   0  223 4128 491  1  1 98
 0 0 0  151468 1542308    0   0   0   0   0   0   0   0  202  154 446  0  0 100
 0 0 0  151468 1542308    0   0   0   0   0   0   0   0  195  148 437  0  0 100
 0 0 0  151468 1542308    0   0   0   0   0   0   0   0  200  150 441  0  0 100
 0 0 0  151468 1542304    1   0   0   0   0   0   0   0  192  148 430  0  0 100
 0 0 0  149372 1543400    0   0   0   0 274   0   0   0  202  217 445  0  0 100
 procs      memory      page                    disks     faults      cpu
 r b w     avm    fre  flt  re  pi  po  fr  sr ad4 ad6   in   sy  cs us sy id
 1 0 0  148156 1544608    2   0   0   0 304   0   0   0  201  163 447  0  0 100
 0 0 0  148156 1544608    0   0   0   0   0   0   0   0  199  154 442  0  0 100
 0 0 0  148156 1544608    0   0   0   0   0   0   0   0  192  148 430  0  0 100
 0 0 0  148156 1544608    0   0   0   0   0   0   0   0  187  146 423  0  0 100
 0 0 0  148924 1543864  186   0   0   0   0   0   0   5  202  153 456  0  0 100
 0 0 0  149756 1543064  200   0   0   0   0   0   0   0  187  171 434  0  0 100
 0 0 0  149756 1543064    0   0   0   0   0   0   0   0  191  148 430  0  0 100
 0 0 0  149756 1543064    0   0   0   0   0   0   0   0  208  154 457  0  0 100
 0 0 0  149756 1543064    0   0   0   0   0   0   0   0  252  145 522  0  0 100
 0 0 0  149756 1543064    0   0   0   0   0   0   0   0  221  130 467  0  0 100
 0 0 0  149756 1543064    0   0   0   0   0   0   0   0  218  347 499  0  0 100
 0 0 0  149756 1543064    0   0   0   0   0   0   0   0  183  130 406  0  0 100
 0 0 0  149756 1543064    0   0   0   0   0   0   0   3  192  132 425  0  0 100
 0 0 0  149756 1543064    0   0   0   0   0   0   0   0  205  130 439  0  0 100

Сбор статистики был запущен до запроса и окончен после. Вобщем пока даже и не ясно, что можно сделать.

AlexKiriukha ★★★★
() автор топика
Ответ на: комментарий от AlexKiriukha

Как и предполагалось, CPU ничего не делает, все время ждем диска. Судя по соотношению количества читаемого к затраченному времени, шаримся по всей таблице. Варианта спасения два:

1. Поставить в машину столько памяти чтоб вся таблица влезла в кеш диска. При начале работы системы пускать что-то вроде "select count(*) from table" чтобы все затащило в кеш.

2. Перекорежить таблицу так что бы интересующие записи лежали рядом. Например юзать clustered primary key или partitioning. В качестве теста этой идеи можно сделать вот что:

create table dict2 as select * from dict order by word;

-- потом создать все индексы на dict2

и попробовать проблемный select. если поможет, можно уже решать как это упорядочивание там перманентно иметь.

gods-little-toy ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← разработка БД
Development
Кому нечем занятся (Нужна простая Fuse FS) →