Телеграмм чат группы pgsql страница 11927

17:45пожаловаться #1

am

Ilya Kaznacheev🥤

А если вместо апдейта юзать? Насколько просадка будет?

Вопрос вот какой: хочу реализовать у сущности один метод для сохранения, чтобы если в бд нету, создавала, а если есть - обновляла.
Но инсертов будет мало, а апдейтов много в соотношении

Если у вас не планируется параллельной записи, то просто сначала делайте SELECT, он практически бесплатный. А потом решайте, INSERT или UPDATE.
Если параллельная запись планируется, то у вас кроме апсерта выхода нет.

17:52пожаловаться #2

W

Warstone in pgsql – PostgreSQL

Если у вас не планируется параллельной записи, то просто сначала делайте SELECT, он практически бесплатный. А потом решайте, INSERT или UPDATE.
Если параллельная запись планируется, то у вас кроме апсерта выхода нет.

Ну почему... Эксклюзивный лок таблицы...

17:53пожаловаться #3

am

Очень смешно.

Ilya Kaznacheev🥤 in pgsql – PostgreSQL

17:53пожаловаться #4

IK

Если у вас не планируется параллельной записи, то просто сначала делайте SELECT, он практически бесплатный. А потом решайте, INSERT или UPDATE.
Если параллельная запись планируется, то у вас кроме апсерта выхода нет.

Параллельно не планируется, все параллельные операции будут только на уже созданной сущности и с локом

17:54пожаловаться #5

D

Daniel in pgsql – PostgreSQL

Ilya Kaznacheev🥤

А если вместо апдейта юзать? Насколько просадка будет?

Вопрос вот какой: хочу реализовать у сущности один метод для сохранения, чтобы если в бд нету, создавала, а если есть - обновляла.
Но инсертов будет мало, а апдейтов много в соотношении

Привет!) Выглядит всё так, словно для этого и создавался функционал INSERT...ON CONFLICT. Только можно ещё посоветовать покрутить fillfactor и попробовать HOT update'ы

17:54пожаловаться #6

am

Ilya Kaznacheev🥤

Параллельно не планируется, все параллельные операции будут только на уже созданной сущности и с локом

Ну вот для таких случаев в моем б-гомерзком ORM’е есть метод find_or_create_by, который это самое и делает.

Ilya Kaznacheev🥤 in pgsql – PostgreSQL

17:55пожаловаться #7

IK

Ну вот для таких случаев в моем б-гомерзком ORM’е есть метод find_or_create_by, который это самое и делает.

Да не, при желании я могу разделить два случая, и при создании делать именно INSERT, а при апдейте именно UPDATE. Я просто упростить код на уровне приложения хотел

к предыдущему: SELECT+UDATE быстрее, чем INSERT ON CONFLICT UPDATE?

17:56пожаловаться #8

am

Должно быть.
Но если вам негде проверить, то вам и париться об этом не надо.

Daniella Starchenko in pgsql – PostgreSQL

18:01пожаловаться #9

DS

Привет. У меня в pg_stat_activity ежедневно появляются одинаковые запросы в двух разных бекендах client backend и worker background. Попадают они туда по расписанию. Вопрос: почему вдруг программная отправка шлет запрос в бекенд client backend? Разве сюда не должны идти запросы, которые идут от pgadmin? B как изменить бекенд?

Konstantin Knizhnik in pgsql – PostgreSQL

18:03пожаловаться #10

KK

Если у вас не планируется параллельной записи, то просто сначала делайте SELECT, он практически бесплатный. А потом решайте, INSERT или UPDATE.
Если параллельная запись планируется, то у вас кроме апсерта выхода нет.

Выходы есть. Можно написать функцию на plpgsql и перехватывать ошибки. Но вряд ли этим стоит заниматься. Используйте INSERT ON CONFLICT и не парьтесь.

18:04пожаловаться #11

b

blkmrkt in pgsql – PostgreSQL

Можно как-нибудь узнать значение определенной настройки уровня сессии для PID?

18:06пожаловаться #12

D

Daniel in pgsql – PostgreSQL

Должно быть.
Но если вам негде проверить, то вам и париться об этом не надо.

А за счёт чего SELECT+UDATE должно быть быстрее, чем INSERT ON CONFLICT UPDATE?

18:06пожаловаться #13

am

Daniel

А за счёт чего SELECT+UDATE должно быть быстрее, чем INSERT ON CONFLICT UPDATE?

Это надо код читать, а мне лень.

Владислав in pgsql – PostgreSQL

18:07пожаловаться #14

В

День добрый, подскажите, насколько время обновления с 9.4 до 13 зависит от объема данных в базе? Мне казалось что там используются hard links и время обновления не должно сильно зависеть от объема данных

18:10пожаловаться #15

VY

Victor Yegorov in pgsql – PostgreSQL

Daniella Starchenko

Привет. У меня в pg_stat_activity ежедневно появляются одинаковые запросы в двух разных бекендах client backend и worker background. Попадают они туда по расписанию. Вопрос: почему вдруг программная отправка шлет запрос в бекенд client backend? Разве сюда не должны идти запросы, которые идут от pgadmin? B как изменить бекенд?

это вы про backend_type? там тип подключение: клиентская сессия, параллельный воркер, фоновый процесс и т.д.

Daniella Starchenko in pgsql – PostgreSQL

18:10пожаловаться #16

DS

Victor Yegorov

это вы про backend_type? там тип подключение: клиентская сессия, параллельный воркер, фоновый процесс и т.д.

да, client backend может выставляться, когда запрос сделан не через клиент бд, а через программный код?

Daniella Starchenko in pgsql – PostgreSQL

18:11пожаловаться #17

DS

показалось, что не должно

18:11пожаловаться #18

VY

Victor Yegorov in pgsql – PostgreSQL

Владислав

День добрый, подскажите, насколько время обновления с 9.4 до 13 зависит от объема данных в базе? Мне казалось что там используются hard links и время обновления не должно сильно зависеть от объема данных

через pg_upgrade если, то да, hard links. время зависит от сложности схемы (pg_dump+pg_restore schema-only) + время сбора статистики (но это уже на запущенной базе).
обычно в 10-20 минут можно уложиться

18:12пожаловаться #19

VY

Victor Yegorov in pgsql – PostgreSQL

Daniella Starchenko

да, client backend может выставляться, когда запрос сделан не через клиент бд, а через программный код?

с точки зрения базы — GUI, psql, приложения через libpq/odbc/jdbc — это всё клиенты