вы ещё на 9.2 сидите?

Думаю, это один из популярнейших вопросов будет ))

Для аудита grep!

студента с берданкой наймите что бы в прямом эфире логи просматривал

шаг влево, шаг вправо - не тот запрос и pg_cancel_backend()

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

студента с берданкой наймите что бы в прямом эфире логи просматривал

Конечно, поэтому на физфаке встречаемся!

Напитки за свой счет! Извините!

Сегодня ещё и у нас митап. Как же везде успеть? Если интересны темы и будете в стороне севера Москвы велкам https://www.meetup.com/Moscow-Atlassian-User-Group/events/244246987/

@Komzpa, @pasha_golub, коллеги, а не спам ли сия объява? Думаю я, что таки спам.

@Komzpa, @pasha_golub, коллеги, а не спам ли сия объява? Думаю я, что таки спам.

Почему это спам?

@Komzpa, @pasha_golub, коллеги, а не спам ли сия объява? Думаю я, что таки спам.

Ну, не знаю.

ЗЫ. Приходилось мне заниматься эксплуатацией продукции сей компании. Воспоминания не вот уж приятные.

ЗЫ. Приходилось мне заниматься эксплуатацией продукции сей компании. Воспоминания не вот уж приятные.

Сколько людей столько и мнений

Все велкам. Здоровая критика это только плюс)

За конфлю - отдельный пламенный привет.

Все велкам. Здоровая критика это только плюс)

Я не хочу критиковать Вашу продукцию. Я хочу, чтобы ваша компания горела в аду.

Это не моя продукция) я админ и пользователь

Деплоймент этого творения и настройка интеграции между продуктами отдельный кайф. Тот случай когда команды явно не пересекаются даже для обсуждения общих концепций. Спам однозначно (сэлз наверное)

ой да што вы токсичные такие их поделия вроде на постгресах работают

@nietzschebrod вот именно - поделия.

да и постгрес то ещё поделие, если разобраться

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

Постгрес - открытое и свободное поделие!

ой да што вы токсичные такие их поделия вроде на постгресах работают

Спасибо, добрый человек!

как будто это что-то меняет

Здравствуйте, уважаемые, вопрос такой назрел по архитектуре БД: Есть бд логов, туда в сутки падает от миллиона 4килобайтных сообщений. В пике до 20 млн. Размером от 4 гига ежесуточно. Таблицы типа ДАТА_УСТРОЙСТВО. Их 1500+ за 45 дней. Оставить так или перейти к схеме - 1 таблица со всеми устройствами и настроить партиционирование?

Здравствуйте, уважаемые, вопрос такой назрел по архитектуре БД: Есть бд логов, туда в сутки падает от миллиона 4килобайтных сообщений. В пике до 20 млн. Размером от 4 гига ежесуточно. Таблицы типа ДАТА_УСТРОЙСТВО. Их 1500+ за 45 дней. Оставить так или перейти к схеме - 1 таблица со всеми устройствами и настроить партиционирование?

Оставить так и настроить партиционирование.

Оставить так и настроить партиционирование.

В офиц доке говориться, что постгрес работает на сотнях партиций, но не работает на тысячах

Здравствуйте, уважаемые, вопрос такой назрел по архитектуре БД: Есть бд логов, туда в сутки падает от миллиона 4килобайтных сообщений. В пике до 20 млн. Размером от 4 гига ежесуточно. Таблицы типа ДАТА_УСТРОЙСТВО. Их 1500+ за 45 дней. Оставить так или перейти к схеме - 1 таблица со всеми устройствами и настроить партиционирование?

Еще есть вариант не создавать primary key, а держать только BRIN индекс. Тогда можно хоть в одной таблице все держать

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

Еще есть вариант не создавать primary key, а держать только BRIN индекс. Тогда можно хоть в одной таблице все держать

В одной таблице тяжко - удалять приходится...

В офиц доке говориться, что постгрес работает на сотнях партиций, но не работает на тысячах

Это на одну таблицу

Это на одну таблицу

Хочешь сказать, сделать партиционирование каскадным?

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

Будет удобнее чистить

привет, а есть что-то типа cte, только для констант? хотелось бы для читабельности вынести подзапрос из SELECT a + b + (SELECT ...), в что-то типа WITH c = (SELECT ...) SELECT a + b + c;

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

запросы могут быть -"а дай мне ошибки за полтора месяца по устройству"

А postgres умеет composite partitioning? Например range-hash как Oracle?

Поэтому частичное партиуионирование не катит... ЛИбо всё, либо ничего.

А postgres умеет composite partitioning? Например range-hash как Oracle?

Тут констрайнтами, вероятно, может. Не знаю за Оракл

привет, а есть что-то типа cte, только для констант? хотелось бы для читабельности вынести подзапрос из SELECT a + b + (SELECT ...), в что-то типа WITH c = (SELECT ...) SELECT a + b + c;

временная таблица? (если это вообще табличная "константа")

временная таблица? (если это вообще табличная "константа")

Это одно число

тогда зачем ему нечитабельный подзапрос?

стековерфлоу говорит что нужен plpg

Ребята, а кто нибудь расскажите почему блокируется таблица при ALTER TABLE "positions_attrs_values" ADD COLUMN "partner_id" integer NULL CHECK ("partner_id" >= 0); ? вроде же не надо создавать никаких новых таплов для этого и перепаковывать таблицу... или это из-за check ?

Ребята, а кто нибудь расскажите почему блокируется таблица при ALTER TABLE "positions_attrs_values" ADD COLUMN "partner_id" integer NULL CHECK ("partner_id" >= 0); ? вроде же не надо создавать никаких новых таплов для этого и перепаковывать таблицу... или это из-за check ?

из-за check: "Adding a CHECK or NOT NULL constraint requires scanning the table to verify that existing rows meet the constraint, but does not require a table rewrite." https://www.postgresql.org/docs/current/static/sql-altertable.html

спасибо

тогда зачем ему нечитабельный подзапрос?

Потому что число нужно достать. Процедуру неохота городить

Ребята. А в pgAdmin посмотреть все существующие данные?

Мда) Просмотр данных в этом Объекте

подскажите плиз как стартануть ПГ - 10

зачем то хомяк сам обновился на 10

и postgres -D /usr/local/var/postgres не работает

или как даунгрейднуться до 9/6

подскажите плиз как стартануть ПГ - 10

Какая OS?

osx

через brew?

там же написано, что делать при апгрейде

В одной таблице тяжко - удалять приходится...

Партиционировать так, чтоб было удобно удалять, IMHO.

там это где)

если в /usr/local/var/postgres осталось файло от 9ки и pg_upgrade или brew cleanup не делали еще, то даунгрейд делается с помощью brew switch postgresql 9.6.5

там это при установке новой версии пакета. в т.ч. при brew upgrade или при brew info postgresql

вот именно что я не устанавливал новых версий)

так как устанавливали-то, через homebrew или нет

я имею ввиду, что я установил через brew

9.6.5

f jy gjnjv e;t rfr njcfv j,yjdbkcz yt cghfibdfz vtyz

он потом сам обновился не спрашивая меня)

так не бывает

но я повторюсь, brew switch спасет отца русской демократии )

да) спасибо

откатился

если захочется апгрейднуться, то гасите сервер: brew services stop postgresql переименовываете папку mv /usr/local/var/postgres /usr/local/var/postgres9 переключаетесь обратно на 10ку brew switch postgresql 10.0 делаете pg_upgrade pg_upgrade -d /usr/local/var/postgres9 -D /usr/local/var/postgres -b /usr/local/Cellar/postgresql/9.6.5/bin/ -B /usr/local/Cellar/postgresql/10.0/bin/ как-то так, наверное. мог что-то пропустить/забыть

Еще есть вариант не создавать primary key, а держать только BRIN индекс. Тогда можно хоть в одной таблице все держать

А как этим брином пользоваться? Есть толковая статья, а то в офиц доке как-то куцо.

А как этим брином пользоваться? Есть толковая статья, а то в офиц доке как-то куцо.

Да просто индекс. Если таймстемпы подряд писать, то работает быстро и почти не проседает по скорости с ростом таблицы (в отличии от b-tree).

Но если вам надо быстро удалять старые таблицы, то это не сильно поможет

Да просто индекс. Если таймстемпы подряд писать, то работает быстро и почти не проседает по скорости с ростом таблицы (в отличии от b-tree).

Как будто B-tree сильно проседает...

Как будто B-tree сильно проседает...

Проседает. Это одна из причин партиционирования. Иногда из-за удобвства поддержки небольших таблиц делают партиции, а иногда из-за того что жирная таблица с b-tree становится медленнее на запись

Проседает. Это одна из причин партиционирования. Иногда из-за удобвства поддержки небольших таблиц делают партиции, а иногда из-за того что жирная таблица с b-tree становится медленнее на запись

А доказательства этого утверждения есть?

А доказательства этого утверждения есть?

Доказательства того что у большого б-дерева дольше сплит делать?

Можете взять pgbench на -s 10 -s 10000 и проверить

Доказательства того что у большого б-дерева дольше сплит делать?

Не сущесвенно, даже теоретически. Взять-то можно, а кто-то проверял?

А доказательства этого утверждения есть?

А доказательства этого утверждения есть?

Я серьёзно. Вообще, когда кто-то начинает рассказывать о "драматических" выгодах партиционирования, я почему-то всегда непроизвольно думаю, что либо кто-то что-то криво померял, либо БД, в которой это работает, сама по себе довольно крива. :(

Речь за разные индексы была, нет?

Я серьёзно. Вообще, когда кто-то начинает рассказывать о "драматических" выгодах партиционирования, я почему-то всегда непроизвольно думаю, что либо кто-то что-то криво померял, либо БД, в которой это работает, сама по себе довольно крива. :(

https://www.slideshare.net/AnastasiaLubennikova/indexes-dont-mean-slow-inserts

16 слайд

Драматические выгоды чтения треда перед высказыванием мнения

https://www.slideshare.net/AnastasiaLubennikova/indexes-dont-mean-slow-inserts

Не открывается сейчас почему-то...

Драматические выгоды чтения треда перед высказыванием мнения

Ну-ну...

Потому что Россия

Не открывается сейчас почему-то...

потому что это линкедин теперь, который заблочен

https://www.slideshare.net/AnastasiaLubennikova/indexes-dont-mean-slow-inserts

Ну и? Это про batch insert, верно?

Драматические выгоды чтения треда перед высказыванием мнения

Так доказательства какие-то есть, всё же? Не какие-то выкладки, а какие-нибудь корректные benchmarks?