спасибо

спасибо

То есть да, reload-а достаточно. А то как-то непонятно ответил. ;)

Всем привет. Хочу сделать репликацию через слоты. Можно ли сделать так: поднимается слот на мастере, делается pg_basebackup на стэндбае и при этом веб-приложения продолжают работать с базой?

или обязательно нужно, чтобы не было обращений к БД?

или обязательно нужно, чтобы не было обращений к БД?

При репликации переносится wal. Максимум ожидания - это один чанк. Если это не критично, то можно не ждать окончания обращений.

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

Даже не заметите

При репликации переносится wal. Максимум ожидания - это один чанк. Если это не критично, то можно не ждать окончания обращений.

у нас база несколько сотен Гб. Соответственно сначала перенесется всё, кроме последнего wal?

у нас база несколько сотен Гб. Соответственно сначала перенесется всё, кроме последнего wal?

Basebackup делает снимок всего кластера и потом дописывает wal, которые есть. А дальше уже репликация догоняет

Это прям очень гениально с точки зрения идеи придумано. Меня это восхищает :)

Всем привет. Ребята, кто с обертками работал. Что лучше, красивее и быстрее? foreign table -> table с триггером на обновление и селектить из таблицы на PG ЛИБО foreign table -> materialized view и refresh в расписании, скажем

И знает ли кто, возможна ли группировка схем?

Всем привет. Ребята, кто с обертками работал. Что лучше, красивее и быстрее? foreign table -> table с триггером на обновление и селектить из таблицы на PG ЛИБО foreign table -> materialized view и refresh в расписании, скажем

"Лучше" для чего? Зачем вообще обёртка, какое именно FDW?

И знает ли кто, возможна ли группировка схем?

Тех, которые CREATE SCHEMA? Нет, это одноуровневая модель.

Basebackup делает снимок всего кластера и потом дописывает wal, которые есть. А дальше уже репликация догоняет

т.е. мне всё-равно надо будет останавливать приложения? Я просто хотел завтра сделать репликацию и мне необходимо, чтобы во время репликации приложения работали

т.е. мне всё-равно надо будет останавливать приложения? Я просто хотел завтра сделать репликацию и мне необходимо, чтобы во время репликации приложения работали

Нет.

т.е. мне всё-равно надо будет останавливать приложения? Я просто хотел завтра сделать репликацию и мне необходимо, чтобы во время репликации приложения работали

Нет, не надо останавливать.

postgres_fdw, тащим данные с Sybase и MSSQL, они обновляются там, тащим на PG (не спрашивайте, зачем). Нужно быстренько усечь часть данных и прогнать на них процедурки.

А усекать до не получится?

postgres_fdw, тащим данные с Sybase и MSSQL, они обновляются там, тащим на PG (не спрашивайте, зачем). Нужно быстренько усечь часть данных и прогнать на них процедурки.

Я ничего не понял. :( postgres_fdw Вы зачем используете? Заливаете данные из MS SQL на другой сервер (или базу?) PostgreSQL, а потом оттуда тащите? > Нужно быстренько усечь часть данных и прогнать на них процедурки. Как усечь? И зачем тут обёртки? :(

@antihaos @SergeyPpro спасибо. И последний вопрос - узнать прогресс репликации можно через pg_replication_origin_progress()?

Усекать до можно, надо замерять, что быстрее, создание foreign таблицы в принципе не занимает большого времени, тут больше вопрос к идеологии, и к тому, как грамотно. На одной базе, которой ведает Sybase лежит огромное количество различных процедур, часть из которых работают плохо. Было принято решение часть процедур для ежедневного выполнения перетянуть на pg, ясен красен, данные нужно брать с прежнего сервера, используем обертки. Как усечь? Брать данные за последний день, например. При всем этом должен быть задел на то, чтобы точку входа подсунуть PG напрямую

Тех, которые CREATE SCHEMA? Нет, это одноуровневая модель.

спасибо

Возможно стоит создать отдельную схему для подобных вещей, и тогда в принципе будет неважно, как данные представлять, либо использовать ту же структуру, но подливать данные в материализованые вьюхи, чтобы соблюдать смысловое разграничение. Может просто у кого-то был опыт с замерами всего этого дела, ибо тянуть данные напрямую с обертки оооооочень долго.

Усекать до можно, надо замерять, что быстрее, создание foreign таблицы в принципе не занимает большого времени, тут больше вопрос к идеологии, и к тому, как грамотно. На одной базе, которой ведает Sybase лежит огромное количество различных процедур, часть из которых работают плохо. Было принято решение часть процедур для ежедневного выполнения перетянуть на pg, ясен красен, данные нужно брать с прежнего сервера, используем обертки. Как усечь? Брать данные за последний день, например. При всем этом должен быть задел на то, чтобы точку входа подсунуть PG напрямую

То есть, postgres_fdw тут на самом деле ни при чём? А что за процедуры, что-то вроде отчётов? А если нет, куда Вы их результаты будете сохранять? > Как усечь? Брать данные за последний день, например. По идее, да, можно сделать matview на FDW, и обновлять "по требованию". А вот как и что вы хотите делать триггерами, я не понял. :(

> тянуть данные напрямую с обертки оооооочень долго. В смысле, тянуть прямо из foreign table? Да, это запросто, т.к. большинство FDW (кроме postgres_fdw), эээ... не очень качественные. ;)

Не совсем, я так полагаю, до меня обертки для серверов/баз создали и они присутствуют в pg. Да, типа отчетов. Можно по требованию, но лучше делать обновление через расписание (мне это видится оптимальным решением) перед запуском тестов. В каком-нибудь cron. Предыдущий сотрудник писал триггеры, которые обновляют усеченные таблицы на PG. Но имхо это неудобно и некрасиво. Хватит двух сущностей, еще третью создавать(( Да, из foreign table. Подсовывать процедурам данные из foreign table - неэффективно (капитаню, наверное) Да, я так понимаю, работать людям есть куда))

@antihaos @SergeyPpro спасибо. И последний вопрос - узнать прогресс репликации можно через pg_replication_origin_progress()?

Вы здесь не путаете рпликацию с бэкапом?

Вы здесь не путаете рпликацию с бэкапом?

у меня есть база, её нужно реплицировать на несколько пока пустых серверов

Возможно стоит создать отдельную схему для подобных вещей, и тогда в принципе будет неважно, как данные представлять, либо использовать ту же структуру, но подливать данные в материализованые вьюхи, чтобы соблюдать смысловое разграничение. Может просто у кого-то был опыт с замерами всего этого дела, ибо тянуть данные напрямую с обертки оооооочень долго.

А каким образом можно подливать в материализованные вьюхи? Разве так можно?

refresh materialized view concurrently

с уникальным индексом на вьюхе

можно использовать refresh

Не совсем, я так полагаю, до меня обертки для серверов/баз создали и они присутствуют в pg. Да, типа отчетов. Можно по требованию, но лучше делать обновление через расписание (мне это видится оптимальным решением) перед запуском тестов. В каком-нибудь cron. Предыдущий сотрудник писал триггеры, которые обновляют усеченные таблицы на PG. Но имхо это неудобно и некрасиво. Хватит двух сущностей, еще третью создавать(( Да, из foreign table. Подсовывать процедурам данные из foreign table - неэффективно (капитаню, наверное) Да, я так понимаю, работать людям есть куда))

> Можно по требованию, но лучше делать обновление через расписание (мне это видится оптимальным решением) перед запуском тестов. В каком-нибудь cron. Расписание — это всего лишь регулярный вызов "по требованию". :)

Ну да) формулировки - враг программиста

у меня есть база, её нужно реплицировать на несколько пока пустых серверов

Затем эти сервера будут непрерывно получать изменения от исходной базы?

Не совсем, я так полагаю, до меня обертки для серверов/баз создали и они присутствуют в pg. Да, типа отчетов. Можно по требованию, но лучше делать обновление через расписание (мне это видится оптимальным решением) перед запуском тестов. В каком-нибудь cron. Предыдущий сотрудник писал триггеры, которые обновляют усеченные таблицы на PG. Но имхо это неудобно и некрасиво. Хватит двух сущностей, еще третью создавать(( Да, из foreign table. Подсовывать процедурам данные из foreign table - неэффективно (капитаню, наверное) Да, я так понимаю, работать людям есть куда))

> Предыдущий сотрудник писал триггеры, которые обновляют усеченные таблицы на PG. Но имхо это неудобно и некрасиво. Хватит двух сущностей, еще третью создавать(( Вот этого-то я и не понял. :( Триггеры где, в PostgreSQL? Так они не "чувствуют" обновлений на "той стороне" (в MS SQL, например).

с уникальным индексом на вьюхе

А зачем использовать уникальный индекс?

А зачем использовать уникальный индекс?

иначе нельзя обновлять в фоне

Спасибо!

А зачем использовать уникальный индекс?

a) Потому что он обязан быть в каждом relation в RDBMS, по-хорошему. ;) б) Потому что тогда работает REFRESH MATERIALIZED VIEW CONCURRENTLY.

refresh materialized view concurrently

То есть при этом старые данные так и останутся и заменятся/допишутся новыми данными?

concurency в pg пока не трогал. По моим ощущениям, вьюха полностью обновляется

Просто не блокируется на время обновления

Не совсем, я так полагаю, до меня обертки для серверов/баз создали и они присутствуют в pg. Да, типа отчетов. Можно по требованию, но лучше делать обновление через расписание (мне это видится оптимальным решением) перед запуском тестов. В каком-нибудь cron. Предыдущий сотрудник писал триггеры, которые обновляют усеченные таблицы на PG. Но имхо это неудобно и некрасиво. Хватит двух сущностей, еще третью создавать(( Да, из foreign table. Подсовывать процедурам данные из foreign table - неэффективно (капитаню, наверное) Да, я так понимаю, работать людям есть куда))

> Подсовывать процедурам данные из foreign table - неэффективно (капитаню, наверное) Ну да, скорее всего. Я так понимаю, что многие FDW делают по принципу "для начала пусть хоть-как то работает"... что потом переходит в "да ладно, и так сойдёт". ;) > Да, я так понимаю, работать людям есть куда)) Это да.

То есть при этом старые данные так и останутся и заменятся/допишутся новыми данными?

Да, старые останутся, новые обновятся/допишутся (или удалятся).

@antihaos @SergeyPpro спасибо. И последний вопрос - узнать прогресс репликации можно через pg_replication_origin_progress()?

pg_replication_origin_progress() относится к логической репликации. pg_basebackup скорее к физической.

Просто не блокируется на время обновления

Это второй эффект, да.

Да, "не чувствуют", все правильно, обновление раньше было в расписании, проглядел.

Да, старые останутся, новые обновятся/допишутся (или удалятся).

Это интересно. Я вот недавно думал, как делать временные olap кубы лучше всего на pg.

Это интересно. Я вот недавно думал, как делать временные olap кубы лучше всего на pg.

Но запрос VIEW выполняется полностью, в любом случае. Поэтому ручное триггерное обновление таблицы-"view" (в том числе, с задержкой, если нужно) может быть куда эффективнее... но его ещё надо написать. ;)

А еще такой момент- можно как то сделать непрерывный wal? Чтобы проинициализировал кластер и дальше все что происходит копилось и можно было отматывать на любой интервал в начало при желании? Так вообще в практике делается ? Или это плохая идея?

Хм, может быть, кстати говоря. Ну это не сложно, мне просто не хочется хранить еще одну процедуру, если можно refresh накидать во вьюхи. 5млн записей рефрешатся за пару минут

Но запрос VIEW выполняется полностью, в любом случае. Поэтому ручное триггерное обновление таблицы-"view" (в том числе, с задержкой, если нужно) может быть куда эффективнее... но его ещё надо написать. ;)

Ну мне надо было как то полностью результат запроса мержить с предыдущим по временному измерению

Грубо говоря метрики на каждый день

А еще такой момент- можно как то сделать непрерывный wal? Чтобы проинициализировал кластер и дальше все что происходит копилось и можно было отматывать на любой интервал в начало при желании? Так вообще в практике делается ? Или это плохая идея?

Это обычное архивирование WAL... разве нет (просто ничего не удалять оттуда)? Но лучше всё же иметь в дополнение к нему basebackup-ы — а то замучаетесь накатывать WAL-ы за полгода, например. ;)

Это обычное архивирование WAL... разве нет (просто ничего не удалять оттуда)? Но лучше всё же иметь в дополнение к нему basebackup-ы — а то замучаетесь накатывать WAL-ы за полгода, например. ;)

Ну точно. Что-то я перемудрил. :) это ж оно и есть.

Кстати, никому не доводилось, может быть чисто случайно использовать jdbc для sybase 2003? Все перерыл, ни в какую. Pg в этом плане просто чудо. С IDEA в связке работать очень удобно

Затем эти сервера будут непрерывно получать изменения от исходной базы?

да, мне нужно "склонировать" БД с репликацией без простоя приложений

user будет жить. Поприветствуем!

@unknown000000 будет жить. Поприветствуем!

@ChazzyChaz будет жить. Поприветствуем!

подскажите, есть ли простой способ написать свою агрегатную функцию в запросе? например просуммировать квадраты четных значений выборки? или в целом условные выражения в агрегации?

Maks Rybalkin будет жить. Поприветствуем!

подскажите, есть ли простой способ написать свою агрегатную функцию в запросе? например просуммировать квадраты четных значений выборки? или в целом условные выражения в агрегации?

Свои агрегаты можно писать на С. Но это весьма не просто. Для того, чтобы просуммирвать квадраты чётных значений можно вставить проверку на чётность в WHERE. Конечно если вы в одном запросе хотите получить и квадраты чётных и квадраты нечётных, то так не получится.

Свои агрегаты можно писать на С. Но это весьма не просто. Для того, чтобы просуммирвать квадраты чётных значений можно вставить проверку на чётность в WHERE. Конечно если вы в одном запросе хотите получить и квадраты чётных и квадраты нечётных, то так не получится.

спасибо! я примерно так и думал, но вдруг что-то не знал и можно. Конечно как-то так наверное можно написать: sum(CASE WHEN ... THEN a*a ELSE NULL END). Но имел ввиду я конечно именно функции.

https://www.postgresql.org/docs/11/static/sql-expressions.html#SYNTAX-AGGREGATES В агрегатах можно указывать фильтр. Позволяет в ряде случаев обходится без CASE.

@matyushkins будет жить. Поприветствуем!

https://www.postgresql.org/docs/11/static/sql-expressions.html#SYNTAX-AGGREGATES В агрегатах можно указывать фильтр. Позволяет в ряде случаев обходится без CASE.

спасибо! да. наверное в принципе на базе существующих наборов можно выстроить нужную агрегацию большинства применений

@sobol будет жить. Поприветствуем!

@knizhnik , подскажите, а вот эта штука - IMCS - живая или уже не сильно?

Да, старые останутся, новые обновятся/допишутся (или удалятся).

не получается сделать, чтобы данные накапливались. происходит замена, а не добавление. Оно точно умеет дописывать/обновлять?

не получается сделать, чтобы данные накапливались. происходит замена, а не добавление. Оно точно умеет дописывать/обновлять?

Да. Что именно Вы делаете? Можете команды показать?

create materialized view neo_olap as select s,now() as v from generate_series(0,10) s; create unique index ON neo_olap (s,now);

refresh materialized view concurrently neo_olap ;

в таблице/вьюхе всегда остается 11 строк

а хотелось бы 11, 22, 33

create materialized view neo_olap as select s,now() as v from generate_series(0,10) s; create unique index ON neo_olap (s,now);

Не-не. Вы на свой уникальный индекс посмотрите — всё правильно работает. Такой в приниципе может обновляться только целиком.

а хотелось бы 11, 22, 33

Так и запрос VIEW-а у Вас должен при каждом последующем обновлении возвращать 11, 22, 33 строк. Такого, чтобы содержимое VIEW-а не соответствовало его запросу, у Вас не получится.

угу. вот и я думал как так может быть и мечтать уже начал ?

приходится делать insert into ... from вьюха

угу. вот и я думал как так может быть и мечтать уже начал ?

Я же Вам писал — запрос VIEW всегда выполняется полностью. ;)

я это понял что выполняется полностью, но тело не очищается ?