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

2021 February 04

ГА

Но если, на поиграться, то чем больше тем лучше. Можно с приоритетами и синхронная\асинхронная поиграться.
С двумя узлами не интересно.

источник

10:59пожаловаться #1

ГА

Георгий Ава... in pgsql – PostgreSQL

Еще момент, для каждой связки мастер+слэйвы в конфигах
Особое внимание на параметры:

scope: "11-main" ----------------------------- название кластера patroni, на всех серверах одинаковое
namespace: "/postgresql-common/" ------- пространство имен(корень) для DCS(etcd), все настройки кластера будут размещаться в нем. На всех серверах одинаковое.

scope для разных связок, должно быть разное.

источник

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

YS

Yaroslav Schekin in pgsql – PostgreSQL

Den

Добрый день. Есть умельцы, которые могут восстановить БД 1С на postrges из бэкапа? Бэкап с ошибками, но полный и читаемый.

> Бэкап с ошибками, но полный и читаемый.

Эээ... что? ;) В смысле, о каком backup речь, что за ошибки и т.п.?
Кстати, тут где-то есть чат специально про postgres+1С — может, там помогут?

источник

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

AH

Artyom Harutyunyan in pgsql – PostgreSQL

Всем привет!
Есть таблица users в него хочу добавить поле jsonB которое по крайней мере будет хранить больше 10 000 записей, вопрос насколько это продуктивно ? то есть при выборке пользователя вместе с ним всегда будет подгружаться массив данных с 10 000 и больше значений, это как то помешает на скорость выдачи результата? заранее спасибо

источник

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

ГА

Георгий Ава... in pgsql – PostgreSQL

Artyom Harutyunyan

Всем привет!
Есть таблица users в него хочу добавить поле jsonB которое по крайней мере будет хранить больше 10 000 записей, вопрос насколько это продуктивно ? то есть при выборке пользователя вместе с ним всегда будет подгружаться массив данных с 10 000 и больше значений, это как то помешает на скорость выдачи результата? заранее спасибо

Может лучше отдельную таблицу.

источник

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

AH

Artyom Harutyunyan in pgsql – PostgreSQL

Георгий Ава

Может лучше отдельную таблицу.

просто не хочеться join писать, чтобы не нагружать систему

источник

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

SG

Sergey Gr in pgsql – PostgreSQL

Artyom Harutyunyan

Всем привет!
Есть таблица users в него хочу добавить поле jsonB которое по крайней мере будет хранить больше 10 000 записей, вопрос насколько это продуктивно ? то есть при выборке пользователя вместе с ним всегда будет подгружаться массив данных с 10 000 и больше значений, это как то помешает на скорость выдачи результата? заранее спасибо

Скорее всего технологически это поле ляжет в TOAST и не будетподгружаться без необходимости.

источник

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

SB

Sergey Bezrukov in pgsql – PostgreSQL

Artyom Harutyunyan

Всем привет!
Есть таблица users в него хочу добавить поле jsonB которое по крайней мере будет хранить больше 10 000 записей, вопрос насколько это продуктивно ? то есть при выборке пользователя вместе с ним всегда будет подгружаться массив данных с 10 000 и больше значений, это как то помешает на скорость выдачи результата? заранее спасибо

Если эти данные нужны при каждом извлечении - то почему бы и нет, в противном случае вы можете просто не выбирать эту колонку в селекте если она вам не нужна, например для построение списка пользователей (id, ФИО)

источник

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

ХБ

Ходад Бродад... in pgsql – PostgreSQL

Георгий Ава

Но если, на поиграться, то чем больше тем лучше. Можно с приоритетами и синхронная\асинхронная поиграться.
С двумя узлами не интересно.

Тут уже не поиграться. Надо базы с нескольких серверов стащить на новый кластер из 2 физических. Проблема ещё и в том, что они закупались для mssql с минимумом ядер. Понятно, что надо делать инстансы, но не совсем понятно, как ресурсы делить.

источник

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

ХБ

Ходад Бродад... in pgsql – PostgreSQL

Георгий Ава

Еще момент, для каждой связки мастер+слэйвы в конфигах
Особое внимание на параметры:

scope: "11-main" ----------------------------- название кластера patroni, на всех серверах одинаковое
namespace: "/postgresql-common/" ------- пространство имен(корень) для DCS(etcd), все настройки кластера будут размещаться в нем. На всех серверах одинаковое.

scope для разных связок, должно быть разное.

Во, спасибо!

источник

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

ГА

Георгий Ава... in pgsql – PostgreSQL

Ходад Бродад

Тут уже не поиграться. Надо базы с нескольких серверов стащить на новый кластер из 2 физических. Проблема ещё и в том, что они закупались для mssql с минимумом ядер. Понятно, что надо делать инстансы, но не совсем понятно, как ресурсы делить.

Вы для каждой бд хотите отдельный инстанс?

источник

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

ГА

Георгий Ава... in pgsql – PostgreSQL

просто обычно, один сервер=один инстанс(несколько бд)

источник

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

YS

Yaroslav Schekin in pgsql – PostgreSQL

Artyom Harutyunyan

просто не хочеться join писать, чтобы не нагружать систему

А почему Вы думаете, что JOIN будет "нагружать систему"?

> то есть при выборке пользователя вместе с ним всегда будет подгружаться массив данных

Так этот массив Вам нужен в выборке (тогда сравнивать с вариантом, когда нет, бессмысленно) или нет (если нет — не выбирайте это поле)?

источник

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

ХБ

Ходад Бродад... in pgsql – PostgreSQL

Георгий Ава

Вы для каждой бд хотите отдельный инстанс?

Консультируюсь с разрабами на этот счёт. Если какие-то базы есть похожие, то наверное можно объединить.

источник

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

ХБ

Ходад Бродад... in pgsql – PostgreSQL

Георгий Ава

просто обычно, один сервер=один инстанс(несколько бд)

Обычно - да. Но есть база для вэб например, а есть для хранения ключей и куча других типов. Они по разному ресурсы потребляют. По хорошему их конечно надо на отдельные разделы ставить, но их тоже нет

источник

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

YS

Yaroslav Schekin in pgsql – PostgreSQL

Ходад Бродад

Обычно - да. Но есть база для вэб например, а есть для хранения ключей и куча других типов. Они по разному ресурсы потребляют. По хорошему их конечно надо на отдельные разделы ставить, но их тоже нет

Т.е. ресурсов, к тому же, в принципе мало (не хватает для нормальной работы, даже если вообразить идеальное разделение), или как?

источник

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

ХБ

Ходад Бродад... in pgsql – PostgreSQL

Ну по 8 физических ядер на сервер и 256 оперативки. С дисками пока проблема - под базы всего терабайт

источник

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

А

Александр in pgsql – PostgreSQL

на девелоперской машине PG10 в докере пытаюсь заполнить новую колонку int8 в таблице на 9gb ~40млн строк. операция уже продолжается 10+ часов. Как понять что оно вообще работает?

источник

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

YS

Yaroslav Schekin in pgsql – PostgreSQL

Ходад Бродад

Ну по 8 физических ядер на сервер и 256 оперативки. С дисками пока проблема - под базы всего терабайт

Ну так мы нагрузку-то не знаем, для нас смысла в этих числах немного. ;)
Вопрос-то в том, "потянет" оно (адекватно) или нет, в принципе.
К примеру, если нет — толку вокруг этого ходить? В "железо" нужно вкладываться.
Ну и так далее.

источник

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

YS

Yaroslav Schekin in pgsql – PostgreSQL

Александр

на девелоперской машине PG10 в докере пытаюсь заполнить новую колонку int8 в таблице на 9gb ~40млн строк. операция уже продолжается 10+ часов. Как понять что оно вообще работает?

Найти этот процесс в pg_stat_activity, посмотреть, что с ним.
Посмотреть, что делает этот pid, средствами OS.

источник

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