Кто мой pg_arman с ptrack потестит?

Кто эти люди? И что нужно для тестов?

у меня из-за этого целая полка за две недели забивается такой фигней

-F t

Занимает почти столько же, как заархивированный плейн дамп

индексы не жмутся так, как вы декларируете, увы

> А зечем вы её дампами забиваете ? скорее бэкапами

Кто эти люди? И что нужно для тестов?

https://gist.github.com/stalkerg/dda6fed9ca4bd7cc424ad439bac04303

> А зечем вы её дампами забиваете ? скорее бэкапами

А в бекапа нет индексов.

Они создаются при ресторе

Будьте здоровы!

А в бекапа нет индексов.

смотря как бекапить

pg_dump

тогда да

по

по этому pg_dump не самый хороший способ для бекапа

долго востанавливать

зато меньше места

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

www.opennet.ru/opennews/art.shtml?num=44463

www.opennet.ru/opennews/art.shtml?num=44463

да там что то они мутят в ветке про 10 я уже устал читать

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

ну в целом факт... бывало что трудно было обяснить почему именно 3 цыфра это минор

да там что то они мутят в ветке про 10 я уже устал читать

Олег Бартунов уже писал, что будет-таки 9.6

ну малоли... всегда всё можно поменять

это в режиме архивлогов нужно держать базу, место больше занимает наверн

ну если важнее место, чем данные, то вы наверно правы

https://habrahabr.ru/company/postgrespro/blog/301238/ а что вы думаете про повышение битности счетчика?

ну если важнее место, чем данные, то вы наверно правы

на продакшн конечно режим arhivelog нужен, а вот для дева кажется и логического дампа может хватить

для дева ты должен либо забирать с прода, либо генерить данные

зачем их бакапить?

кому-то может и не нужно, разные случаи могут быть

для дева ты должен либо забирать с прода, либо генерить данные

Это когда есть понимание что там лежит и как, а оно, как показывает практика, не всегда есть, легаси, все дела )

кому-то может и не нужно, разные случаи могут быть

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

если прод в банке, а дев отдельная компания, то такое даже с обезличиванием архисложно и не совсем правильно

если прод в банке, а дев отдельная компания, то такое даже с обезличиванием архисложно и не совсем правильно

А как правильно?

А как правильно?

генерить данные, но это не всегда тривиальная задача (чтоб похоже на правду было)

и лучше сразу об этом подумать, потом оно гораздо легче будет

думать - оно всегда лучше )

делать стенд такой же конфигурации как прод, настраивать так же, и да, генерить данные

Привет Вадим

мне? Привет)

0_0

Вадим? Костя?

Боря?

Привет тебе

:)

Чего

Все свои

Хихи

Без бороды

а че не бреешься, Кость?)) Там же жарко

Ну не не бреюсь

Борода наше все

Сингапуррра

Вадим, пойдем уже нагрузочные тесты проведем

Вместо обмена фотками с Костей

:)

?

Хихихи

Соскучился я по вам мужики :-)

:)

В отпуск в РФ

)))

Не скоро ещё

В отпуск в РФ

слишком дорого

слишком дорого

:)

Завтра поеду в Индонезию

Далеко просто

Не не дорого, долго

Наш офис

На английском говорите?

Смесь китайского. Малайского, инглиша

чинглиш

Диалект

Я больше стараюсь на китайском

Сложно очень

Сад орхидей

Эко акция по очистке пляжа

?

Ну как то так

Могу блог организовать если надо

Озвучте профиль только как и чего

Что хотите узнать и тд,

Было бы интересно почитать про "наших там"

Форум русского клуба в сингапуре

Всем доброго дня. А какие проблемы могут вознкнуть если все запросы на измнения собирать во что-то типа with "q0" AS (insert into "a" ("id") values (1) RETURNING ("id")), "q1" AS (insert into "a" ("id") values (2) RETURNING ("id")) select * from q0 union q1 плюсы - насколько понимаю, такой запрос будет быстрей работать, или нет?

Explain analyze вам покажет

@dbalakov добрый. быстрей, чем insert into a(id) values(1), (2) returning id?

@olshevskiy_dv там будут разнородные запросы на insert, update, delete, select