Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности

Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
19.04.2006, 05:42
|
|||
|---|---|---|---|
Индексы в ,большой таблице с частыми INSERT |
|||
|
#18+
Есть большая таблица (десятки млн записей) в определенные промежутки времени в нее вставляется по 2000 записей. По этой же таблице делается суммирование (за промежутки времени,по ним и создан индекс). Для ускорения этой операции и некоторых других созданы индексы,которые тормозят INSERT, но без них сильно тормозят запросы. Как быть в этой непростой ситуации? Сейчас удаляю индекс перед INSERTами,но потом они создаются продолжительное время.Может есть др приемы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.04.2006, 09:03
|
|||
|---|---|---|---|
|
|||
Индексы в ,большой таблице с частыми INSERT |
|||
|
#18+
А что инсерты так уж сильно тормозят? 2000 записей? Не верю. Вернее, могу поверить, если скажете, что у вас 20 индексов: по 3-4 поля + индексы по выражениям/функциям +- GIST индексы. Ладно, поверю в любом случае, только скажите - сколько это "тормозят" в секундах (с индексами/без индексов)? Да, и какая версия postgresql? на 8.1 возможно лучше использовать несколько одностолбцовых индексов (особенно для суммирования - по опыту говорю) - postgre сам их объединяет с помощью bitmap. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.04.2006, 09:11
|
|||
|---|---|---|---|
|
|||
Индексы в ,большой таблице с частыми INSERT |
|||
|
#18+
Нужно сделать очередь. Один из вариантов: Создаешь таблицу А. От нее наследуешь таблицу B. Все вставки осуществляешь в Б. Затем пишешь скрипт который постоянно крутится и выполняет сл. дейстия. begin; insert into temp table tmp select * from B; delete from B where id in (select id from tmp); insert into A select * from tmp; drop table tmp; commit; наследование очень удобно в том плане что select * from A будет выдавать все записи включая те что в B. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.04.2006, 09:40
|
|||
|---|---|---|---|
|
|||
Индексы в ,большой таблице с частыми INSERT |
|||
|
#18+
> По этой же таблице делается суммирование Может, есть смысл хранить промежуточные результаты? > которые тормозят INSERT sar, iostat? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.04.2006, 11:08
|
|||
|---|---|---|---|
Индексы в ,большой таблице с частыми INSERT |
|||
|
#18+
тормоза просто на простых индексах при таком объеме вставки маловероятны. скорее всего они у вас уникью (т.е. вызывают триггер на каждой строке, и вообще склонны к лоченью - если конкурентная транза поюзала такое же значение уника). я наблюдал сильное падение скорости при вставках при наличии форейн-кеев и прочих риференсов (такоже порождающих позаписные триггеры). приходилось убивать кеи в начали транзакции, далее согласованным запросом (чтобы не навставлять записей не имеющих родителей - после чего ключи уж точно не подымуцца) вливать записи, и, наконец, поднимать кеи. Получался даже выигрыш раз в 5 (не смотря на то, что поднятие кеев вещь совсем не шустрая). Вот с тех пор и думаю, что стейтментные триггера в таких случаях работали бы много шибче позаписных, будь в постгресе такие штукки как INSERTED и DELETED. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|

start [/forum/topic.php?fid=53&tablet=1&tid=2006458]: |
0ms |
get settings: |
10ms |
get forum list: |
17ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
43ms |
get topic data: |
14ms |
get forum data: |
4ms |
get page messages: |
56ms |
get tp. blocked users: |
2ms |
| others: | 244ms |
| total: | 398ms |

| 0 / 0 |
