это трим

кто на конференции? на какой следующий доклад идёте и почему?

Пошёл на поиск проблем с репликацией. Докладчик в прошлом году произвёл впечатление глубоко разбирающего в постгресе. Сейчас на секционирование. На патрони был в прошлый раз

Блин, ну вот офигенно в минорном релизе переименовать службу и поменять $PGDATA

Я сопровождаю постгрес с 3к pl/sql процедур. Вся логика в базе.

а как изменение логики отслеживаете? есть GIT?

а как изменение логики отслеживаете? есть GIT?

я не отслеживаю, это полностью на совести прогеров

там ещё и не одна команда работает

вообще сначала всё на тестовом обкатывается и потом переносится (руками, вероятно)

гемор(

хочу http://blog.gitora.com/tag/documentation/ попробовать

может кто юзал, отзыв хотелось бы услышать

подскажите почему когда я делаю в пг delete from вывод показывает что удалено столько то а место на жд не освобождаетя. автовакуум включен

подскажите почему когда я делаю в пг delete from вывод показывает что удалено столько то а место на жд не освобождаетя. автовакуум включен

только full vacuum

может кто юзал, отзыв хотелось бы услышать

+1

тоесть после удаления обязательно выполнять?

Мы сейчас миграции бекэнда юзаем. Все это в гит + codereview

Но это имхо для бд костыль изза отсутствия альтернатив

Было бы идеально continuous integration юзать для бд

тоесть после удаления обязательно выполнять?

Если нужно место освободить от удалённых строк, да.

почему то место наоборот увеличивается

почему то место наоборот увеличивается

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

Мы сейчас миграции бекэнда юзаем. Все это в гит + codereview

так удобно жешь?

Ну как бе идеально, если контроль схемы был наглядно. Конфирмы по коммитам изменений схемы

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

Тем более зависимости от расширений также не контролируются

Ну если о боли говорить

привет! :)

девопсы не добрались до DBA еще походу

каждый свою моднячую NoSQL базу пилит

Бодрый вечер! Кто-нибудь работал с кэшом Redis над RDBMS? Интересно опытное мнение, минусы, проблемы.

это k/v хранилище, прямо вот над rdbms он кэшем быть не может, только над подмножеством запросов

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

минусы и проблемы - cache invalidation, что же еще

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

Угу, тоже так делал раньше, совсем лишним оно оказалось

коточат)))

Мурмур

выше еще манул и рыжик есть))

А кто не любит котов ? ? Все любят.

Это смотря как приготовишь

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

Альтернативу in memory можете порекомендовать?

А как вы ею планируете пользоваться?

Альтернатива слонов чему?

В каких задачах?

что-то туплю

как это сагригировать, заменив null’ы на имеющиеся данные?

Ggo

как это сагригировать, заменив null’ы на имеющиеся данные?

Это базовая таблица?

да, не вьюха

Мб стоит запрос изменить, а не результат его. Как выглядит запрос?

да это не запрос тут какое дело…

пользователь вводит адреса в форме документа, и они (адреса) попадают в базу обязательные поля это build и room, поля floor и entrance не обязательные при каждой отправке формы содается строка в таблице (дубликаты тоже), затем финальный триггер агрегирует адреса мне нужно сагрегировать адреса таким образом, что если пользователь когда-то ввел необязательные этаж/подъезд, то они при агрегации заменяли пустые значения в ранее введенных адресах как-то так

Можно выбрать distinct и отсортировать по null first (если может встретится в т.ч. строка в которой нет значений (но есть нулы)). Можно выбрать по is not null. можно оконными lead/lag поискать.

пиздец как обидно ((((( раньше целые приложения вокруг разряженных данных в оракле писал забыл все (

ERROR: S client not available

Можно выбрать distinct и отсортировать по null first (если может встретится в т.ч. строка в которой нет значений (но есть нулы)). Можно выбрать по is not null. можно оконными lead/lag поискать.

спасиб, покурю доки

Первый вариант вас скорее всего устроит

Еще, если не ошибаюсь, можно сгруппировать так: select build, room, arr_agg(distinct floor), arr_agg(distinct entrance) from table group by build, room. Но нулы в массивах (или любой другой агрегации) тоже будут. И 3, 4 поля фильтровать в приложении (подбрасывать в качестве выбора, например).

пиздец как обидно ((((( раньше целые приложения вокруг разряженных данных в оракле писал забыл все (

WITH you_table AS ( SELECT unnest(ARRAY[1, 2, 1, 4]) AS build, unnest(ARRAY[1, 2, 1, 4]) AS room, unnest(ARRAY[NULL, 2, 3, NULL]::int[]) AS floor, unnest(ARRAY[NULL, NULL, 4, NULL]::int[]) AS entrance ) SELECT build, room, json_agg(DISTINCT floor) FILTER (WHERE floor IS NOT NULL) AS floor, json_agg(DISTINCT entrance) FILTER (WHERE entrance IS NOT NULL) AS entrance FROM you_table GROUP BY build, room; build | room | floor | entrance -------+------+-------+---------- 1 | 1 | [3] | [4] 2 | 2 | [2] | 4 | 4 | | (3 rows)

Подзапрос, это

build | room | floor | entrance -------+------+-------+---------- 1 | 1 | | 2 | 2 | 2 | 1 | 1 | 3 | 4 4 | 4 | | (4 rows)

Я исходил из того, что в таблице может быть несколько разных этажей/парадных

Люди могут и ошибиться (а в таблице с нуллами редко кто делает корректные check констрейнты) – этим должно рулить приложение и этаж и парадную "подкидывать" в поле.

интересно… спасибо большое!

как бы скажу крамолу, но может просто по крону бегать и заполнять этажи и подъезды или чо там. Не стоит усложнять сущности без необходимости...

тут нет "разряженных данных" есть квартира и дом. остальное додумает яндекс карты...

тут нет "разряженных данных" есть квартира и дом. остальное додумает яндекс карты...

ясное дело, что нет ))) а вот с задачей в фоне это идея..

Подскажите, чем принято инициировать регулярные операции списания средств/баллов и прочих ресурсов? В голову приходят только cron/pg_cron.

pgagent

Подскажите, чем принято инициировать регулярные операции списания средств/баллов и прочих ресурсов? В голову приходят только cron/pg_cron.

е-мейлы посылать нужно, когда баллы кончились?

если да, то лучше крон и приложение

е-мейлы из транзакций не очень хорошо отправлять. :)

Дорофей приходи лучше во второй зал, тут Олег про новомодный json вещает))

А как вы ею планируете пользоваться?

Идея была в загрузке кэша Redis данными из MySQL.

если переформулировать - какие запросы вы планируете к нему делать?

то что там данные будут - я и так понимаю

е-мейлы посылать нужно, когда баллы кончились?

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

Чтение аппликации - множественные селекты, включая dashboards. Время возврата нужно минимальное.

давайте в @dba_ru с максимально полным описанием кейса (потому что селекты по kv вы делать не сможете, и пока это все не очень хорошо бьется)

давайте в @dba_ru с максимально полным описанием кейса (потому что селекты по kv вы делать не сможете, и пока это все не очень хорошо бьется)

Запостил?

Приглашаем всех на доклад (17:30 Зал 1, сегодня) (доклад только вчера появился в программе) Тема: "Эффективная работа с 10+ ПБ данных в PostgreSQL или новая парадигма построения "бережливых" инфраструктур данных для Data-Driven Enterprise" Алексей Мергасов ...о технических деталях и опыте применения подхода экстремальной нормализации данных для создания инфраструктур данных с уникальными потребительскими характеристиками. В сравнении с решениями лидеров рынка такие инфраструктуры обладают, например, такими преимуществами, как: - оперативная обработка 10 ПБ данных и больше, - в 2-6 раз более высокая производительность, - сквозная 100% консистентность данных, - практически линейная горизонтальная масштабируемость, - в 4-10 более низкая стоимость владения, - и т. д. Изложенный подход уже нашел применение за пределами России в решениях для операторов связи, ритейла, финтеха, современном производстве (Industry 4.0, индустриальный IoT), в государственном секторе. Подробности: https://pgconf.ru/2017/95634