Вот что выдал describe

Подскажите, есть ли способ делать запросы в две идентичные таблицы (одна активная, другая архивная), как в одну большую. Копаю в сторону UNION, но есть ньюансы при джоинах и аггрегатных функциях.

Подскажите, есть ли способ делать запросы в две идентичные таблицы (одна активная, другая архивная), как в одну большую. Копаю в сторону UNION, но есть ньюансы при джоинах и аггрегатных функциях.

Сделалйте view через union над ними

https://www.db-fiddle.com/f/4md9Vy1fYG8xx1tPnJRMYN/0

Сделалйте view через union над ними

Делал, и всплыла одна проблема при аггрегации. В примере выше требуемый запрос к отдельным таблицам (там всё хорошо) и к union-у (пока тоже всё хорошо). Но стоит добавить аггрегацию по characteristic - начинабтся проблемы.

Работает только так: https://www.db-fiddle.com/f/4md9Vy1fYG8xx1tPnJRMYN/2 Но перечислять все поля в GROUP BY как-то не очень.

Работает только так: https://www.db-fiddle.com/f/4md9Vy1fYG8xx1tPnJRMYN/2 Но перечислять все поля в GROUP BY как-то не очень.

Мне кажется стандарт требует этого.

Полагаю, что когда делаешь запрос в реальную таблицу с группировкой только по primary key, система понимает, что ничего аггрегировать не придётся. А при запросе к представлению PK уже как-бы отсутствует.

Вместо SELECT total_table.*, ... GROUP BY id, some_field1, some_field2 ещё можно сделать SELECT id, min(some_field1) as some_field1, min(some_field2) as some_field2 ... GROUP BY id - что тоже работает. Но по мне, так это ещё большее извращение, чем первый вариант. Поэтому и спрашиваю, может кто знает более правильный вариант.

Вместо SELECT total_table.*, ... GROUP BY id, some_field1, some_field2 ещё можно сделать SELECT id, min(some_field1) as some_field1, min(some_field2) as some_field2 ... GROUP BY id - что тоже работает. Но по мне, так это ещё большее извращение, чем первый вариант. Поэтому и спрашиваю, может кто знает более правильный вариант.

Вы просто привыкли к хорошему. :) Раньше (относительно недавно, кстати) functional dependencies даже в стандарте не было, и все перечисляли поля.

кстати, а с какой версии так можно делать стало?

кстати, а с какой версии так можно делать стало?

С 9.1, кажется.

Вместо SELECT total_table.*, ... GROUP BY id, some_field1, some_field2 ещё можно сделать SELECT id, min(some_field1) as some_field1, min(some_field2) as some_field2 ... GROUP BY id - что тоже работает. Но по мне, так это ещё большее извращение, чем первый вариант. Поэтому и спрашиваю, может кто знает более правильный вариант.

Например, если очень хочется, можно так: CREATE TABLE some_data(id serial PRIMARY KEY, payload text NOT NULL); CREATE TABLE some_historical_data() INHERITS (some_data); INSERT INTO some_data(payload) VALUES ('parent'); INSERT INTO some_historical_data(payload) VALUES ('child'); SELECT * FROM some_data GROUP BY id;

Ребят. Юзаю постгрес 10, необходимо сделать синхронную репликацию. Данные в основном пишутся , нагркзка небольшая. В какую сторону лучше смотреть? Стабильна ли логическая?

Тебе всю базу полностью необходимо реплицировать, или только некоторые каталоги/страницы?

Warning FailedScheduling 3m (x3754 over 10h) default-scheduler pod has unbound PersistentVolumeClaims

Ну вот и проблема. Можете сделать describe pvc <name> и посмотреть чего это под него PV не создается

Ну вот и проблема. Можете сделать describe pvc <name> и посмотреть чего это под него PV не создается

PV не создаётся из-за отсутствия provisioner'а

Ребят. Юзаю постгрес 10, необходимо сделать синхронную репликацию. Данные в основном пишутся , нагркзка небольшая. В какую сторону лучше смотреть? Стабильна ли логическая?

Цель репликации какая?

Цель репликации какая?

Два цода. Клиент попадает на любой из них. Данные должны быть актуальны. В случае падения одной из баз приложение отправит на другой цод

Два цода. Клиент попадает на любой из них. Данные должны быть актуальны. В случае падения одной из баз приложение отправит на другой цод

Т.е. в норме клиент попадает только на primary (master), так? Вы, кстати, понимаете, что такой setup, в общем-то, не увеличивает, а уменьшает надёжность? ;)

Т.е. в норме клиент попадает только на primary (master), так? Вы, кстати, понимаете, что такой setup, в общем-то, не увеличивает, а уменьшает надёжность? ;)

А какой правильный сетап? Должна быть синхронность. В каждом цоде по инстансу. Цодов два

А какой правильный сетап? Должна быть синхронность. В каждом цоде по инстансу. Цодов два

Вы подробнее-то расскажите, всё же — ответьте на вопрос, например.

Например, если очень хочется, можно так: CREATE TABLE some_data(id serial PRIMARY KEY, payload text NOT NULL); CREATE TABLE some_historical_data() INHERITS (some_data); INSERT INTO some_data(payload) VALUES ('parent'); INSERT INTO some_historical_data(payload) VALUES ('child'); SELECT * FROM some_data GROUP BY id;

Спасибо. Однако, при попытке сделать запрос SELECT * FROM some_historical_data GROUP BY id; возникает всё та же проблема(

Вы подробнее-то расскажите, всё же — ответьте на вопрос, например.

В норме клиент попал в цод1, приложение записало чтото в бд цод01. Другой попал на цод2, а там бд должна быть уже синхронизирована с бд из цод01

Спасибо. Однако, при попытке сделать запрос SELECT * FROM some_historical_data GROUP BY id; возникает всё та же проблема(

ALTER TABLE some_historical_data ADD PRIMARY KEY(id);

В норме клиент попал в цод1, приложение записало чтото в бд цод01. Другой попал на цод2, а там бд должна быть уже синхронизирована с бд из цод01

Ага, то есть не только на один ЦОД (т.е. не warm standby). Дальше, при streaming replicatiion только одна из баз (primary) будет R/W, Вы к этому готовы?

ALTER TABLE some_historical_data ADD PRIMARY KEY(id);

Спасибо! ? Осталось придумать, как превратить существующую архивную таблицу с данными на боевой базе, созданную с помощью LIKE ... INCLUDING ALL в наследованную)

Спасибо! ? Осталось придумать, как превратить существующую архивную таблицу с данными на боевой базе, созданную с помощью LIKE ... INCLUDING ALL в наследованную)

ALTER TABLE ... INHERIT parent_table;

Ну и вообще, почитайте про наследование и партиционирование.

Спасибо, уже начал.

Мона не стопать базу мастера при переливке на слейв?

вилки нет города нет

Город Москва, зп от 180 до 220 на руки

вилки нет города нет

Москва, 180-220 на руки

в вакансию добавьте, мне то не за чем:)

А удалёнка есть?

Мона не стопать базу мастера при переливке на слейв?

В смысле? Для streaming replication или чего именно?

Мне кажется это вообще бот был

Всем привет. Ищу разработчика PostgreSQL к нам в команду в Московский офис, в компанию Манго Телеком - лидер рынка виртуальных АТС, облачных сервисов и решений, которые помогают нашим клиентам правильно выстроить бизнес-коммуникации и процессы. Задачи: - написание, модификация и оптимизация бизнес-логики на уровне БД - повышение производительности существующих программных модулей От Вас мы ждём опыт работы программистом баз данных PostgreSQL или Oracle не менее 2-х лет, опыт написания хранимых процедур, функций, триггеров, участие в разработке высоконагруженных сервисов. Условия : зп от 180 до 220 Дмс, английский, обучение за счёт компании Печеньки, фрукты, завтраки Офис в шаговой доступности от м. Калужская За подробностями велкам в личку. Резюме присылайте на b.blinova@mangotele.com

А удалёнка есть?

Ярослав, к сожалению, нет, только офис рассматриваем

В смысле? Для streaming replication или чего именно?

Да пофиг что, бекап с слева снимать

Мне кажется это вообще бот был

?

Ну не нравится мне подобный спам, завидовать профессионалам начинаю

Да пофиг что, бекап с слева снимать

Да, конечно можно (если я правильно понял). Я понял так, что есть primary, Вы хотите без его остановки сделать async streaming replica, с которой в дальнейшем будете снимать backups, верно?

Да, конечно можно (если я правильно понял). Я понял так, что есть primary, Вы хотите без его остановки сделать async streaming replica, с которой в дальнейшем будете снимать backups, верно?

Да

Да

https://hunleyd.github.io/posts/PostgreSQL-Streaming-Replication-In-10-Minutes/

https://hunleyd.github.io/posts/PostgreSQL-Streaming-Replication-In-10-Minutes/

В приципе да только wall жругой выбрал пока, надо определиться с ним

Wall level для бекапа какой лучше подойдет всмысле

В приципе да только wall жругой выбрал пока, надо определиться с ним

А какой "другой"?

Какой лучше, для теста реплика щас

Какой лучше, для теста реплика щас

А какая у Вас версия PostgreSQL?

10

10

Тогда replica (это, кстати, default).

Спс

Ухх, я у мамы дба сегодня

Например, так: https://www.db-fiddle.com/f/bBo34U3KZBuWFYicp7Hd3r/3

А что можете сказать про такой вариант? https://www.db-fiddle.com/f/bBo34U3KZBuWFYicp7Hd3r/6

А что можете сказать про такой вариант? https://www.db-fiddle.com/f/bBo34U3KZBuWFYicp7Hd3r/6

Вы этим из любви к искусству занимаетесь? ;) . Во-первых, там ошибка, вместо: order by messages.message_id)->1->>'first_response' as first_response должно быть: order by messages.message_id)->0->>'first_response' as first_response . Во-вторых, страшно представить производительность этого запроса на сколько-нибудь существенных объёмах данных.

Всем привет. Такой вопрос: Как вернуть запись, чтобы одна колонка содержала массив данных из другой таблицы? Пример: таблицы owner и cars. У овнера есть айдишник, и несколько машин. У машины есть номер и марка. Как вот вернуть селектом такие данные: OwnerId | Car 1 | {"num": "NG1221GH", "model":"Ford"},{"num":"bla111bla", "model":"Ferrari"} ?

чтобы я потом смог этот ответ смаппить в объект Owner_And_Car, состоящий из int OwnerId и List<Car> Cars

как-то так

ERROR: S client not available

Всем привет. Такой вопрос: Как вернуть запись, чтобы одна колонка содержала массив данных из другой таблицы? Пример: таблицы owner и cars. У овнера есть айдишник, и несколько машин. У машины есть номер и марка. Как вот вернуть селектом такие данные: OwnerId | Car 1 | {"num": "NG1221GH", "model":"Ford"},{"num":"bla111bla", "model":"Ferrari"} ?

Так не надо делать. Антипаттерн.

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

Всем привет. Такой вопрос: Как вернуть запись, чтобы одна колонка содержала массив данных из другой таблицы? Пример: таблицы owner и cars. У овнера есть айдишник, и несколько машин. У машины есть номер и марка. Как вот вернуть селектом такие данные: OwnerId | Car 1 | {"num": "NG1221GH", "model":"Ford"},{"num":"bla111bla", "model":"Ferrari"} ?

Используй один набор данных, JOIN, ORDER BY

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

Формируй такие данные на клиенте.

и у меня будет 5 записей с одинаковым айдишником и разными машинами, это не подходит

и у меня будет 5 записей с одинаковым айдишником и разными машинами, это не подходит

И в чём проблема?

да проблема как это потом маппить в даппере

да проблема как это потом маппить в даппере

Твой ORM не умеет в 1+?

Всем привет. Такой вопрос: Как вернуть запись, чтобы одна колонка содержала массив данных из другой таблицы? Пример: таблицы owner и cars. У овнера есть айдишник, и несколько машин. У машины есть номер и марка. Как вот вернуть селектом такие данные: OwnerId | Car 1 | {"num": "NG1221GH", "model":"Ford"},{"num":"bla111bla", "model":"Ferrari"} ?

Ну в PG есть массивы и фукнции работы с ними. Если желаешь уж совсем, пожалуйста, изучай, пользуй. Но не каждый клиент умеет их читать. Ну и вообще -- это антипаттерн

Ну в PG есть массивы и фукнции работы с ними. Если желаешь уж совсем, пожалуйста, изучай, пользуй. Но не каждый клиент умеет их читать. Ну и вообще -- это антипаттерн

всегда можно массив в jsonb конвертнуть

Ну если сами себе сложности хотите создавать -- как бы я вам не пастух.

Такие вещи отлично делаются через cte и фенкцию

На выходе которой jsonb

Мы на одном проекте для фронта многие такие чтения перевели на функции

Чтобы orm не насиловала базу

Особенно там, где пагинация по сложному набору данных

Особенно там, где пагинация по сложному набору данных

Ага, а пагинация тебе базу не насилует, ага...

Давайте смотреть на первостепенную задачу

Моя функция возвращает список собранных объектов гораздо быстрее, чем их собирает орм

Моя функция возвращает список собранных объектов гораздо быстрее, чем их собирает орм

То есть, Ваша ORM не может обработать обычный результат запроса? (Интересно, есть ли более-менее "нормальные" ORM-ы вообще...)

я же не сказал, что не может

может

но перф-тесты говорят о том, что делает это медленнее

считаю спор исчерпанным, т.к. я представитель обители зла (все жизнь работаю сугубо с базами данных, последние 6 лет с высоконагруженными), а здесь большинство - представители back-end - поэтому про орм тут принято говорить или хорошо, или никак)

Всем привет. Ищу разработчика PostgreSQL к нам в команду в Московский офис, в компанию Манго Телеком - лидер рынка виртуальных АТС, облачных сервисов и решений, которые помогают нашим клиентам правильно выстроить бизнес-коммуникации и процессы. Задачи: - написание, модификация и оптимизация бизнес-логики на уровне БД - повышение производительности существующих программных модулей От Вас мы ждём опыт работы программистом баз данных PostgreSQL или Oracle не менее 2-х лет, опыт написания хранимых процедур, функций, триггеров, участие в разработке высоконагруженных сервисов. Условия : зп от 180 до 220 Дмс, английский, обучение за счёт компании Печеньки, фрукты, завтраки Офис в шаговой доступности от м. Калужская За подробностями велкам в личку. Резюме присылайте на b.blinova@mangotele.com

Можем предложить аутсорсинг.

Всем привет. Такой вопрос: Как вернуть запись, чтобы одна колонка содержала массив данных из другой таблицы? Пример: таблицы owner и cars. У овнера есть айдишник, и несколько машин. У машины есть номер и марка. Как вот вернуть селектом такие данные: OwnerId | Car 1 | {"num": "NG1221GH", "model":"Ford"},{"num":"bla111bla", "model":"Ferrari"} ?

Например, так: select owner.*, row_to_json(car) from owner join car on (owner.id = owner);

Можем предложить аутсорсинг.

Дмитрий, спасибо, по некоторым проектам работаем по такому формату и хотим уйти, предпочтение человек в штат компании. Спасибо за предложение

Дмитрий, спасибо, по некоторым проектам работаем по такому формату и хотим уйти, предпочтение человек в штат компании. Спасибо за предложение

Штатный сотрудник всегда удобнее с т.з. коммуникации. Но сегодня нет проблем поручать работу регионам, т.к. все условия для этого есть. Вопрос только в отвественности и компетентности.

Штатный сотрудник всегда удобнее с т.з. коммуникации. Но сегодня нет проблем поручать работу регионам, т.к. все условия для этого есть. Вопрос только в отвественности и компетентности.

Согласна, но увы, ИТ директора не переубедить