Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
автор Но вы писали: "смотрел на бегущие инсерты, через часа три бегут значительно медленне". Сколько строк было обработано в вашем тесте за три часа? Беру таймаут на проведение тестов. А вот про апдейты интересно. Действительно где дока? А по задумке данное должно прыгать из таблицы в таблицу минимум 3 раза и только потом в архив.. Похоже плохая задумка :D ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.04.2005, 12:36 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
короче я придумал нужно прыгнуть на ступеньку выше (от техн реализации) 2АК приведи задачу полностью (без существующего решения) откуда поступает инфа и что нужно получить в итоге (и если надо в промежутке) и тогда можно попробовать перестроить схему работы с наименьшими изменениями кстати программера можно подключить :-)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.04.2005, 12:51 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
domanixв даенном случае судя по коду , идет заливка большого массива данных и на каждый инсерт срабатывает триггер который делает update таблицы dev.current_data а мне кажется из программы идет UPDATE через ХП в табл dev.current_data, а только потом срабатывает триггер на INSERT в arh.base_temp1 domanix Так вот - каждый update - рождает в таблице dev.current_data новую версию записи.. соответвенно при моллионе вставленных записей будет миллион версий записей в dev.current_data, ничего каждый UPDATE не рождает и ничего подобного вроде миллиона версий не будет. Те при простых UPDATE (как впрочем и INSERT зависимость будет линейная). Пробовал просто UPDATE в таблицу с индексами и без оных и все впорядке ничего не тормозит попробую еще через хранимку, а потом на все это дело повешу триггер (делаю так потому что интересно прогнать все блоки отдельно и только потом их соеденить) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.04.2005, 09:55 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
Здача глобальна :) Контроль и управление тех процессом. сбор информации, обработка, показ текущего среза на месте оператора. сохранение в архив. Требуется телать некоторые расчеты, на основе принятых данных и отправлять их исполнительным механизмам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.04.2005, 10:08 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
появились новые интересные данные Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. Как видно быстрее сделать 10 раз по 10000 записей чем один раз 100000. К чему бы это? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.05.2005, 20:41 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
vfabr domanixТак вот - каждый update - рождает в таблице dev.current_data новую версию записи.. соответвенно при моллионе вставленных записей будет миллион версий записей в dev.current_data, ничего каждый UPDATE не рождает и ничего подобного вроде миллиона версий не будет. Те при простых UPDATE (как впрочем и INSERT зависимость будет линейная). Ага, не рождает :-) Попробуй следующее: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. При это логов накаталось на 8*16MB=128MB . Кто сказал, что логгирование не тормозит? :-) Настройки постгресса-по умолчанию. Кто добьется хорошего улучшения результата - сообщите. Как кто-то сказал (извини, что поленился найти), да и я сам пробовал, дешевле оказывается использовать plperl и его %_SHARED для накопления результата в FOR EACH ROW и потом сбрасывать результат в FOR EACH STATEMENT. Или еще где-нибудь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2005, 12:16 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
Дополнение: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. Затем: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Код: plaintext 1. 2. 3. 4. 5. 6. 7. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2005, 13:00 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
Алексей КлючниковКак видно быстрее сделать 10 раз по 10000 записей чем один раз 100000.Это можно было заметить и по моим результатам : 4m59.599s / 100 000 > 0m18.317s / 10 000. Но мы не заметили. :) Алексей КлючниковК чему бы это?К вопросу выбора оптимальной длины транзакции. Почему так происходит, не знаю. Funny_Falconupdate group_sum set amount=amount+NEW.ru where group_id=NEW.group_id -- Уже прошло 4970 секунд и не завершилось!попробуйте создать индекс на group_sum.group_id ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2005, 13:15 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
Второй день играю с параметрами в postgresql.conf пока не нашел что бы что то сильно влияло на скорость инсертов. тюнинг операционной системы совсем видимо не скоро удасться сделать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2005, 13:30 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
Алексей Ключниковпока не нашел что бы что то сильно влияло на скорость инсертовfsync? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2005, 13:34 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
LeXa NalBat fsync Неа :) checkpoint_segments #checkpoint_timeout Вот этими параматрами можно сильно попортить скорость.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2005, 13:51 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
LeXa NalBat Funny_Falcon update group_sum set amount=amount+NEW.ru where group_id=NEW.group_id -- Уже прошло 4970 секунд и не завершилось! попробуйте создать индекс на group_sum.group_id Извини, а group_id int PRIMARY KEY по твоему этого не делает ???????? Если нет, то я барсук. Но это еще надо доказать. Построй таблицу, залей в нее много данных (чтоб seqscan не выбирался) и сделай EXPLAIN запроса, содержащего условие по PRIMARY KEY. Там ты увидешь INDEX SCAN. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2005, 17:36 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
Funny_Falcon vfabr domanixТак вот - каждый update - рождает в таблице dev.current_data новую версию записи.. соответвенно при моллионе вставленных записей будет миллион версий записей в dev.current_data, ничего каждый UPDATE не рождает и ничего подобного вроде миллиона версий не будет. Те при простых UPDATE (как впрочем и INSERT зависимость будет линейная). Ага, не рождает :-) Попробуй следующее: первая причина почему не буду пробовать твой пример заключается хотя бы в том, что он не соответствует тому как действительно работает программа АК (смотри страницу 2). У тебя совершенно другая структура. Прежде чем ответить, возьми лист бумаги и нарисуй то что написал АК и то что придумал ты. А после этого посмотри еще раз мой пост [1488436]... И еще я придерживаюсь мнения что если запрос умещается в одну строку в экран то никакую ХП под него лепить не надо, а если не лепить ХП то в случае АК (основываясь на его примере см стр.2) ничего подобного ввиде миллиона записей не будет. далее почему процедура (тригерная) написана как plpgsql? почему не просто sql??? по моему есть разница ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.05.2005, 12:43 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
2 vfabr А ты пробовал триггерную функцию на SQL написать? Лично у меня (Postgres 8.0.2) выдаёт: ERROR: SQL functions cannot return type "trigger" на следующую конструкцию: Код: plaintext 1. 2. 3. 4. 5. А по поводу структуры: не один икс, вставлять в А, потом апдейтить в Б или апдейтить в Б, а потом вставлять в А? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.05.2005, 10:37 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
про trigger на SQL меня бить надо потому что в доке написано что можно реализовать trigger на любом языке встроенном кроме как на чистом SQL :-/ спасибо FF я был не прав насчет А и Б я не скажу прям щас точно насчет логирования и пт но разница есть миллиона записей Update в случае АК не будет потому что происходит автокомит после вызова функции. Может и залогируется 1000000 Insertov, а может и нет. И вообще (ИМХО) структура не совсем верная у базы ... поэтому и тормоза ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.05.2005, 15:03 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
vfabrмиллиона записей Update в случае АК не будет потому что происходит автокомит после вызова функции. Может и залогируется 1000000 Insertov, а может и нет. будут, но делаются по очереди а не пачкой, поэтому и автокоммит. vfabrИ вообще (ИМХО) структура не совсем верная у базы ... поэтому и тормоза Как же производить обработку информации? на current_data навешены набор правил и триггер который переклабывает в архив. ХП нужны в любом случае. Некоторые данные через правила проходят через 5-6 ХП до того как лягут в архив. Поэтому в любом случае нужна такая таблица как current_data, иначе все оберации придется делать в прямо в архиве.. на Данный момент обработке подвергаются 1-0.5% данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.05.2005, 14:40 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
Funny_Falcon LeXa NalBat Funny_Falcon update group_sum set amount=amount+NEW.ru where group_id=NEW.group_id -- Уже прошло 4970 секунд и не завершилось! попробуйте создать индекс на group_sum.group_idИзвини, а group_id int PRIMARY KEY по твоему этого не делает ???????? Угу, слона то я и не заметил. Сорри, беру свой совет назад. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.05.2005, 12:01 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
АКпоэтому и автокоммит автокоммит всегда происходит если не сказанно BEGIN [TRANSACTION] те явным образом не объявлена транзакция. Насчет структуры ... мне кажеться что нужна некоторая буферная таблица (без индексов и прочей мутотени) куда складываются данные (грязные) и потом их обрабатывать и раскидывать куда нужно. Вопрос в скорости отображения результатов полученных от датчиков. Может актуальность в 30 сек или 1 мин вполне приемлема тогда и тригеров и хранимок может меньше понадобится да и загрузка сервака меньше (ИМХО) должна быть ну и тд. (но поскольку я незнаю постановку задачи и темболее не знаю реализацию то все вышесказанное может быть совершенным бредом :-))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.05.2005, 19:34 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=33052372&tid=2007264]: |
0ms |
get settings: |
9ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
49ms |
get topic data: |
6ms |
get forum data: |
2ms |
get page messages: |
31ms |
get tp. blocked users: |
1ms |
| others: | 262ms |
| total: | 374ms |

| 0 / 0 |
