D
я и не говорю, что избавляет
Size: a a a
2021 January 26
D
я хочу понять, почему эта связка должна быть быстрее, чем INSERT ON CONFLICT
KK
А за счёт чего SELECT+UDATE должно быть быстрее, чем INSERT ON CONFLICT UPDATE?
Вряд ли он будет быстрее. Но если не лень - можете проверить. Там на INSERT ON CONFLICT много чего делается. Например спекулятивные таплы вставляются. Так что я не очень удивлюсь, если действительно выигрыш будет. Но вряд ли в разы.
YS
Если у вас не планируется параллельной записи, то просто сначала делайте
Если параллельная запись планируется, то у вас кроме апсерта выхода нет.
SELECT, он практически бесплатный. А потом решайте, INSERT или UPDATE.Если параллельная запись планируется, то у вас кроме апсерта выхода нет.
SERIALIZABLE, как обычно. Хотя INSERT ... ON CONFLICT, опять-таки, быстрее и проще.
D
да, с этим я полность согласен, и то, насколько я понимаю механику, говорит мне о том, что INSERT...ON CONFLICT будет не сильно медленнее, а местами и быстрее, чем SELECT + UPDATE
D
и маленький тестик это слегка подтвердил 😊
KK
Не так давно я также бенчмаркал разные реализации upsert-а.
Правда немного для другого сценария использования.
https://www.postgresql-archive.org/INSERT-ON-CONFLICT-and-RETURNING-tp6150951p6153134.html
Правда немного для другого сценария использования.
https://www.postgresql-archive.org/INSERT-ON-CONFLICT-and-RETURNING-tp6150951p6153134.html
YS
да, с этим я полность согласен, и то, насколько я понимаю механику, говорит мне о том, что INSERT...ON CONFLICT будет не сильно медленнее, а местами и быстрее, чем SELECT + UPDATE
Так INSERT...ON CONFLICT и должен быть быстрее... как и писали: https://t.me/pgsql/278698
D
да да, меня лишь малость смутил ответ: https://t.me/pgsql/278727
K
ORACLE Academy или ищите подготовку на ORACLE Certified Professional
Спасибо
am
Yaroslav Schekin
Так INSERT...ON CONFLICT и должен быть быстрее... как и писали: https://t.me/pgsql/278698
Там все же рассматривался
INSERT — ой — UPDATE, а не SELECT — хм — INSERT/UPDATE.YS
Там все же рассматривался
INSERT — ой — UPDATE, а не SELECT — хм — INSERT/UPDATE.А, так тогда измерять нужно было совсем не то...
Т.е. нужно было UPDATE, если 0 rows updated → INSERT.
Т.е. нужно было UPDATE, если 0 rows updated → INSERT.
am
Ради того, что происходит раз в год, делать нетривиальный анализ каждый раз при... старте/первом обращении к таблице? А если что-то пойдёт не так? Апгрейд - всё-таки планируемая операция, а тут нежданчик може прилететь после каждого рестарта СУБД. Например, флипнулся бит где-нибудь в заголовке таблицы - просто она не будет читаться. А если встроить апгрейд, то можно вообще попортить все данные из-за ложного детекта.
xlog мы переименуем в wal, чтобы неподготовленные пользовали перестали удалять «какие-то логи», а у остальных все скрипты сломались.
am
Зато полбайта прочитать при запуске БД и понять, что там старая версия — это слишком большой оверхед, пусть пользователь сам с утилитой ковыряется.
Иногда бывает сложно понять философию этой базы данных.
Иногда бывает сложно понять философию этой базы данных.
VY
Зато полбайта прочитать при запуске БД и понять, что там старая версия — это слишком большой оверхед, пусть пользователь сам с утилитой ковыряется.
Иногда бывает сложно понять философию этой базы данных.
Иногда бывает сложно понять философию этой базы данных.
какие полбайта?
в коде нужно хранить ветви работы для разных версий. тут не все патчи бэкпатчятся из-за серьезных изменений в коде между мажорками…
в коде нужно хранить ветви работы для разных версий. тут не все патчи бэкпатчятся из-за серьезных изменений в коде между мажорками…
YS
Зато полбайта прочитать при запуске БД и понять, что там старая версия — это слишком большой оверхед, пусть пользователь сам с утилитой ковыряется.
Иногда бывает сложно понять философию этой базы данных.
Иногда бывает сложно понять философию этой базы данных.
А если утилита "грохнется" в процессе? И уже никакой базы.
И вообще, как это так вышло, что новому binary postgres вдруг встретилась старая база?
По-моему, это зачастую значит, что кто-то уже накосил (примерно как с удалением WAL).
И вообще, как это так вышло, что новому binary postgres вдруг встретилась старая база?
По-моему, это зачастую значит, что кто-то уже накосил (примерно как с удалением WAL).
am
какие полбайта?
в коде нужно хранить ветви работы для разных версий. тут не все патчи бэкпатчятся из-за серьезных изменений в коде между мажорками…
в коде нужно хранить ветви работы для разных версий. тут не все патчи бэкпатчятся из-за серьезных изменений в коде между мажорками…
Нет, такого кошмара не надо, конечно. Но запустить тот же pg_upgrade кто мешает, раз это дело на пять минут?
am
Yaroslav Schekin
А если утилита "грохнется" в процессе? И уже никакой базы.
И вообще, как это так вышло, что новому binary postgres вдруг встретилась старая база?
По-моему, это зачастую значит, что кто-то уже накосил (примерно как с удалением WAL).
И вообще, как это так вышло, что новому binary postgres вдруг встретилась старая база?
По-моему, это зачастую значит, что кто-то уже накосил (примерно как с удалением WAL).
А если утилита
pg_upgrade --link «грохнется» в процессе, то старая база гарантированно останется невредимой? Хорошо, уговорили.YS
А если утилита
pg_upgrade --link «грохнется» в процессе, то старая база гарантированно останется невредимой? Хорошо, уговорили.Нет, разумеется. Для того и снимают backup перед upgrade.
N
Через ~10 минут, в 21мск подключайтесь — поздний постгрес-вторник сегодня, http://bit.ly/RuPostgresTuesday
ютуб: https://youtube.com/RuPostgres
ютуб: https://youtube.com/RuPostgres