Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Оптимизация вставок.
|
|||
|---|---|---|---|
|
#18+
Здравствуйте. В постгресе 7.4 проблема - слишком медленные вставки. Вот таблица: Код: plaintext 1. 2. 3. 4. 5. 6. Триггер к ней: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. Смысл триггера - реализовать аналог mysql'евского INSERT INGNORE INTO... Вставки идут очень медленно - постгрес упиратся в диск по кол-ву транзакций. Думаю как раз изза этого триггера. Транзакции использую, т.е. большое число вставок делаю в одной транзакции. Есть ли у кого опыт, как это можно оптимизировать, чтобы вставки шли быстрее? COPY пробовал. Результат тоже не очень. Подумываю о переезде обратно на mysql :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2006, 23:37 |
|
||
|
Оптимизация вставок.
|
|||
|---|---|---|---|
|
#18+
ага переезжай обратно на майскл ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2006, 23:59 |
|
||
|
Оптимизация вставок.
|
|||
|---|---|---|---|
|
#18+
1/ индекс на path.path 2/ Вставка конструкциями ~ INSERT INTO path (.,.,.,.) SELECT ,,, FROM any_t LEFT JOIN path p1 USING (path) WHERE p1.path IS NULL; ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2006, 11:30 |
|
||
|
Оптимизация вставок.
|
|||
|---|---|---|---|
|
#18+
robot648...Смысл триггера - реализовать аналог mysql'евского INSERT INGNORE INTO... Вставки идут очень медленно - постгрес упиратся в диск по кол-ву транзакций. Думаю как раз изза этого триггера. Транзакции использую, т.е. большое число вставок делаю в одной транзакции. Есть ли у кого опыт, как это можно оптимизировать, чтобы вставки шли быстрее? COPY пробовал. Результат тоже не очень. Подумываю о переезде обратно на mysql :( Естественно. У тебя при каждой вставке идет проверка по всей таблице. НА КАЖДУЮ СТРОКУ. Как вариант - попробуй сделать триггер FOR EACH STATEMENT. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2006, 14:29 |
|
||
|
Оптимизация вставок.
|
|||
|---|---|---|---|
|
#18+
43211/ индекс на path.path 2/ Вставка конструкциями ~ INSERT INTO path (.,.,.,.) SELECT ,,, FROM any_t LEFT JOIN path p1 USING (path) WHERE p1.path IS NULL; Благодарю, попробую, орезультатах отпишу. автор Естественно. У тебя при каждой вставке идет проверка по всей таблице. НА КАЖДУЮ СТРОКУ. Как вариант - попробуй сделать триггер FOR EACH STATEMENT. А смысл? мне надо проверять наличие в таблицы именно каждой строки, которую я собираюсь вставить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2006, 16:45 |
|
||
|
Оптимизация вставок.
|
|||
|---|---|---|---|
|
#18+
может уник поставить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2006, 17:05 |
|
||
|
Оптимизация вставок.
|
|||
|---|---|---|---|
|
#18+
robot648 Смысл триггера - реализовать аналог mysql'евского INSERT INGNORE INTO... Вставки идут очень медленно - постгрес упиратся в диск по кол-ву транзакций. Думаю как раз изза этого триггера. Транзакции использую, т.е. большое число вставок делаю в одной транзакции. Есть ли у кого опыт, как это можно оптимизировать, чтобы вставки шли быстрее? COPY пробовал. Результат тоже не очень. Подумываю о переезде обратно на mysql :( Ну варианта тут 2: 1) обратно на mysql, 2) вставлять записи во временную таблицу, потом Код: plaintext 1. 2. 3. 4. 5. 6. 7. а вообще, если требуется INSERT IGNORE, как и любое другое мысклёвое средство проё#а данных, значит чё-то не так с приложением. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2006, 19:26 |
|
||
|
Оптимизация вставок.
|
|||
|---|---|---|---|
|
#18+
ИМХО никакие решения, когда работу ввыполняет постгрес, тут не помогут. Я бы объявил блокирующую транзакцию, перегнал бы эту таблицу в память и при вставке локально выполнял бы все эти проверки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2006, 19:45 |
|
||
|
Оптимизация вставок.
|
|||
|---|---|---|---|
|
#18+
HordiИМХО никакие решения, когда работу ввыполняет постгрес, тут не помогут. Я бы объявил блокирующую транзакцию, перегнал бы эту таблицу в память и при вставке локально выполнял бы все эти проверки. а если много записей (от 10 000) и каждая запись от 3Мб? боюсь что просто не хватит ОЗУ :( или можно как по частям ложить в память? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2007, 11:54 |
|
||
|
Оптимизация вставок.
|
|||
|---|---|---|---|
|
#18+
В дополнение. 1. Если коллизии встречаются достаточно редко, то можно просто в прикладном коде обрабатывать ошибку и игнорировать ее. 2. Если коллизии встречаются достаточно редко, можно попробовать изменить логику приложения таким образом, чтобы записи позволяли вставлять всегда, но реально использовали ту, у которой минимальный ID. Ну и какой-нибудь ночной чистильщик дублей. 3. Поскольку сортировка по path, видимо, не требуется, можно посмотреть на индекс на основе хэшей - должно быть побыстрее. Что на самом деле означает UNIQUE? В исходном письме настораживает фраза "Думаю как раз изза этого триггера". Имело бы смысл это проверить и точно выяснить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2007, 12:48 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=33541895&tid=2004996]: |
0ms |
get settings: |
8ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
67ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
36ms |
get tp. blocked users: |
1ms |
| others: | 238ms |
| total: | 381ms |

| 0 / 0 |
