Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Гуру: Что быстрее delete+insert или select+update+insert ?
|
|||
|---|---|---|---|
|
#18+
Добрый день! Postgres 8.1.3 , win. Есть таблица с расчетными данными, все поля int и numeric, количество записей порядка 1,3 млн. Порция обновляемых данных достигает от 20 до 60 записей. Индекс по полям поиска есть. Вот вопрос: что быстрее будет работать ? Вариант 1: Тупой delete старой порции , потом insert новой. Вариант 2: select старой порции, смотрим на совпадение ключей, по совпавшим делаем update, новые записи инсертим. Примечание: расчетная программа в цикле перебирает счета и обновляет данные (все 1.3 млн записей) Спасибо заранее ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.09.2006, 12:40 |
|
||
|
Гуру: Что быстрее delete+insert или select+update+insert ?
|
|||
|---|---|---|---|
|
#18+
а схема update if rows_affected==0 then insert end if; не покатит? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.09.2006, 12:44 |
|
||
|
Гуру: Что быстрее delete+insert или select+update+insert ?
|
|||
|---|---|---|---|
|
#18+
wbearа схема update if rows_affected==0 then insert end if; Если это про ХП, то нет. Логика не в ХП, а в отдельном приложении. Спасибо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.09.2006, 12:47 |
|
||
|
Гуру: Что быстрее delete+insert или select+update+insert ?
|
|||
|---|---|---|---|
|
#18+
galishaВариант 1: Тупой delete старой порции , потом insert новой. Вариант 2: select старой порции, смотрим на совпадение ключей, по совпавшим делаем update, новые записи инсертим.Или в старой порции нет ключей, отсутствующих в новой, или для того чтобы эти варианты стали эквивалентными нужно к варианту 2 добавить "старые записи удаляем". Голосую за первый вариант, потому что в постгресе update есть маркировка старой строки как deleted (что делается в delete), и добавление новой строки (что делается в insert). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.09.2006, 13:13 |
|
||
|
Гуру: Что быстрее delete+insert или select+update+insert ?
|
|||
|---|---|---|---|
|
#18+
LeXa NalBatпотому что в постгресе update есть маркировка старой строки как deleted Т.е. любой update приводит к тому, что Postgres фактически "забывает" про старую запись. Это так ? Это ж распухание базы будет. И это лечится кажется через VACUUM ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.09.2006, 13:22 |
|
||
|
Гуру: Что быстрее delete+insert или select+update+insert ?
|
|||
|---|---|---|---|
|
#18+
galisha LeXa NalBatпотому что в постгресе update есть маркировка старой строки как deleted Т.е. любой update приводит к тому, что Postgres фактически "забывает" про старую запись. Это так ? Это ж распухание базы будет. И это лечится кажется через VACUUM ?В более старых версиях постгреса было именно так, и лечилось vacuum. В восьмерке вроде бы autovacuum встроен в сервер, то есть должно лечится само. Но досконально этот вопрос не исследовал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.09.2006, 13:29 |
|
||
|
Гуру: Что быстрее delete+insert или select+update+insert ?
|
|||
|---|---|---|---|
|
#18+
Большое спасибо, теперь не буду мучаться с логикой: select+update. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.09.2006, 13:31 |
|
||
|
Гуру: Что быстрее delete+insert или select+update+insert ?
|
|||
|---|---|---|---|
|
#18+
galisha wbearа схема update if rows_affected==0 then insert end if; Если это про ХП, то нет. Логика не в ХП, а в отдельном приложении. Спасибо насколько я понимаю в отдельном приложении rows_affected тоже можно получить. и кстати вопрос Вариант 2: select старой порции, смотрим на совпадение ключей, по совпавшим делаем update, новые записи инсертим. а что делаем с записями которые есть в старой порции но нет в новой? в первом ворианте они удаляются все во втором остаются.? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.09.2006, 16:04 |
|
||
|
Гуру: Что быстрее delete+insert или select+update+insert ?
|
|||
|---|---|---|---|
|
#18+
Там поля со значениями апдейтятся в NULL, а ключевые остаются без изменений. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.09.2006, 17:30 |
|
||
|
Гуру: Что быстрее delete+insert или select+update+insert ?
|
|||
|---|---|---|---|
|
#18+
Проголосую за select+update+insert. Как-то делал игрушечный тест (без селекта правда - delete+insert vs update) - update оказался быстрее. Но вообще тестить надо на реальных данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2006, 09:50 |
|
||
|
Гуру: Что быстрее delete+insert или select+update+insert ?
|
|||
|---|---|---|---|
|
#18+
galisha Примечание: расчетная программа в цикле перебирает счета и обновляет данные (все 1.3 млн записей) Лучше обновлять счета по факту (события). Триггерами. А вот простой пример без всяких select (делаем 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. Да, и логику всё-таки лучше вернуть в БД. :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2006, 10:04 |
|
||
|
Гуру: Что быстрее delete+insert или select+update+insert ?
|
|||
|---|---|---|---|
|
#18+
Funny_FalconНо вообще тестить надо на реальных данных Проверил: delete+insert отработал немного быстрее. Там правда еще много разных вещей попутно делается - но тенденция к ускорению есть для варианта delete+insert. glebofffДа, и логику всё-таки лучше вернуть в БД Иногда это не получается, требования другие. Всем большое спасибо ! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2006, 16:49 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=34010456&tid=2006077]: |
0ms |
get settings: |
9ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
133ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
52ms |
get tp. blocked users: |
1ms |
| others: | 260ms |
| total: | 488ms |

| 0 / 0 |
