|
|
|
Slow query
|
|||
|---|---|---|---|
|
#18+
День добрый! Имею запрос, не слишком сложный - left join по четырем таблицам, where по десятку полей, order по трем и limit. Основная таблица содержит тысяч 20 строк - тестовый режим. Запрос мой отрабатывает за пару секунд, и это неплохо. Если вбросить в основнуй таблицу еще тысяч 10 строк - запрос будет отрабатывать от двух до пяти минут. Если после этого выдать еще один такой же запрос - опять пара секунд. Если тот же запрос выдавать в процессе добавления записей, он отрабатывает примерно за минуту, +- 10 секунд. У меня нехорошее ощущение, что обновление индексов происходит по первому запросу, а не по insert. Может кто-нибудь подтвердить/опровергнуть? А то и указать на ключик, который за такое поведение отвечает? Спасибо With best regards, Daniel Podolsky ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2003, 18:03 |
|
||
|
Slow query
|
|||
|---|---|---|---|
|
#18+
похоже на то ,что че-то с памятью... яб предположил то что при первом заприсе оно выжирает данные с винта в память а во время второго запроса этого уже не происходит.. посмотрел бы че с винтом творится при первом запросе.. если не хрустит то я тогда даже незнаю что предположить а OS какя? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2003, 19:44 |
|
||
|
Slow query
|
|||
|---|---|---|---|
|
#18+
Daniel По утверждениям разработчиков индексы обновляются после каждой транзакции изменяющей ключевые поля - именно этим объясняют невысокую производительность при многочисленных инсертах и включенном автокоммите. Именно поэтому для всатвки пары десятков тысяч записей рекомендуют пользоваться командой COPY. Согласен что пользоваться ей не всегда удобно, но скорость добавления записей IMHO предельная. Что же касается индексов: похоже они обновляются опять таки после коммита транзакции. Наверное тут происходит нарушение статистики на которую опирается планировщик запросов. И где-то он отказывается от индексов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2003, 19:45 |
|
||
|
Slow query
|
|||
|---|---|---|---|
|
#18+
>По утверждениям разработчиков индексы обновляются после >каждой транзакции изменяющей ключевые поля - >именно этим объясняют невысокую производительность >при многочисленных инсертах и включенном автокоммите. Я бы не назвал эту производительность "невысокой" :) Мне удается влить 100,000 записей за 40 минут. Это быстрее, чем мускул и оракул... Данные поступают по ТСР и вливаются через 10 соединений с БД. >Наверное тут происходит нарушение статистики на которую опирается >планировщик запросов. И где-то он отказывается от индексов. Да нет... Если во время insert говорить explain - он показывает соответственное увеличение цены, но все индексы - на месте. А ОС - RedHat 7.3... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2003, 22:32 |
|
||
|
Slow query
|
|||
|---|---|---|---|
|
#18+
Про скорость Insert/Copy - см доку. VACUUM ANALYZE. - полезно обновлять статистику для планировщика после массового перепахивания таблиц. Про RH ничего не знаю. смотри рассылки на postgresql.org. И все-таки тут важнее не ОС а установки постгреса ну и сам запрос. Еще раз скажу - индексы обновляются именно по insert ( именно чтобы не тратить время на их обновление при массовых инсертах в доке рекомендуют удалять индексы и создавать после всех инсертов заново) Следовательно дело не в индексах. IMHO все дело в мусоре и неадекватной статистике для планировщика. Сравни результаты EXPLAIN ANALYZE до и после VACUUM ANALYZE. Я думаю получится интересно. Может быть что-то не в порядке с выполнением WAL под RH. Тут ничего не присоветую. Это к разработчикам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2003, 16:23 |
|
||
|
|
start [/forum/topic.php?fid=53&msg=32173051&tid=2008193]: |
0ms |
get settings: |
9ms |
get forum list: |
11ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
33ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
46ms |
get tp. blocked users: |
1ms |
| others: | 13ms |
| total: | 136ms |
| 0 / 0 |
