хм

а тут бан по маске не канает?

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

@bondarden посмотрите, какие локали у вас в системах установлены и там, и там, locale -a

Привел два сервера к идентичному состоянию. На обоих в locale -a есть одна и та же локаль ru_RU.utf8 На обоих серверах создал одну и ту же базу данных командой: createdb -e -E "UTF-8" -l "ru_RU.UTF-8" -T template0 test Затем подключился к этой базе и создал там коллате CREATE COLLATION numeric (provider = icu, locale = 'uni-u-kn-true'); В итоге результат проверки разный :( SELECT '2' < '10' COLLATE numeric; == false Что еще смотреть?

У нас @Cyberdyne_Systems_bot стоит, он не очень эээ интуитивный, но этих ребят отсеивает. Для работы достаточно было просто добавить его админом с доступом к сообщениям/юзерам.

У нас @Cyberdyne_Systems_bot стоит, он не очень эээ интуитивный, но этих ребят отсеивает. Для работы достаточно было просто добавить его админом с доступом к сообщениям/юзерам.

Удваиваю

Удваиваю

утраиваю, думал он в этом чате)

Привет! Никто не в курсе, Alter Table может выполнять только овнер?

либо тот у кого есть права. емнип

Разрослась одна из таблиц, а места на диске не хватает, чтобы сделать vacuum full. Другие таблицы минимального размера. Индексы тоже ужаты. Как схлопнуть файл таблицы не используя vacuum full??

либо тот у кого есть права. емнип

права на запись и на чтение я запросто раздаю, а по поводу alter table на стекоферфлоу посоветовали изврат типа ALTER ROLE user6 NOINHERIT; GRANT object_owner TO user6;

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

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

Я что-то никак не могу понять, как можно дать права делать ALTER TABLE юзеру, у которого та же роль что и у того, который создавал эту таблицу

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

grant all on table to user?

Да. Лучше ролью.

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

Grant user_owner to user_new

grant all on table to user?

All не поможет

Разрослась одна из таблиц, а места на диске не хватает, чтобы сделать vacuum full. Другие таблицы минимального размера. Индексы тоже ужаты. Как схлопнуть файл таблицы не используя vacuum full??

pg_repack

pg_repack

Спасибо! Но он требует столько же места, сколько занимает таблица. А его нет совсем. Копаю в эту сторону - https://github.com/dataegret/pgcompacttable

All не поможет

Да, вы правы. Роль с правами владельца схемы спасет.

По-моему оптимальней будет всем одну роль присвоить ALTER USER user SET ROLE rw;

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

По-моему оптимальней будет всем одну роль присвоить ALTER USER user SET ROLE rw;

Чёт я не смог воспроизвести так. Либо туплю

у роли есть права на изменение схемы С и U

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

как эти боты достали(

как эти боты достали(

Да надо админов достать, чтоб бота добавили

Не надо админов доставать ;-) Они PG занимаются ;-)

А существует ли какие-нибудь шаблоны проектирования для проектирования схем БД?

А существует ли какие-нибудь шаблоны проектирования для проектирования схем БД?

В смысле?

Нормальные формы ;)

В смысле?

Например, есть сущность группа, есть сущность юзер, есть сущность задачи, которые принадлежат и группе и юзеру, внутри группы у юзеров различные роли. По сути задачи это в некоторым смысле ресурсы группы. Ресурсы можно расшарить между другими группами/юзерами. Какие-нибудь подходы к проектированию подобного рода бд

Например, есть сущность группа, есть сущность юзер, есть сущность задачи, которые принадлежат и группе и юзеру, внутри группы у юзеров различные роли. По сути задачи это в некоторым смысле ресурсы группы. Ресурсы можно расшарить между другими группами/юзерами. Какие-нибудь подходы к проектированию подобного рода бд

Ну, не то что бы я вчитывался, но... разве нормализации не хватает? ;)

Ну, не то что бы я вчитывался, но... разве нормализации не хватает? ;)

Ну мб хватает

Ну мб хватает

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

Но вообще, а что если ряд сущностей имеют часть одинаковых полей. Например, сущность TextNews: - title - description PromotionNews: - title - description - promotion_id - image VideoNews: - title - desctiption - video И в таком духе

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

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

А, ну да, это как раз случай, когда не творит. ;) А чем Вам не нравятся три таблицы? И какие конкретно три таблицы (тут может быть много вариантов, как ни странно)?

А, ну да, это как раз случай, когда не творит. ;) А чем Вам не нравятся три таблицы? И какие конкретно три таблицы (тут может быть много вариантов, как ни странно)?

Ну как раз подобные таблички, только их немного больше(на пару-тройку штук). Якобы есть разные типы новостей с разной информацией, эти новости объединяются в некую группу новостей. На фронт нужно отдавать не просто заголовки всех новостей в определенной группе, а якобы список новостей разных типов. Что-то вроде: group/13/ [ 'news': { full TextNews info }, { full PromotionNews info }, { full VideoNews info } ]

Тут вообще можно одной обойтись

С енумом и jsonb

С енумом и jsonb

Ну не совсем пойдет

Например, если поиск нужен

И?

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

Всю лишнюю мишуру в jsonb

Который отлично индексируется

И?

А я поддержу @bdgwsh — нечего сразу в EAV и его аналоги бросаться (только если уж другого выхода совсем нет).

Который отлично индексируется

Не отлично, на самом деле (разве что "поля" вытаскивать в функциональные индексы). И потом получается "сейчас мы запросто напишем свою СУБД внутри вашей СУБД!". ;)

Ну как раз подобные таблички, только их немного больше(на пару-тройку штук). Якобы есть разные типы новостей с разной информацией, эти новости объединяются в некую группу новостей. На фронт нужно отдавать не просто заголовки всех новостей в определенной группе, а якобы список новостей разных типов. Что-то вроде: group/13/ [ 'news': { full TextNews info }, { full PromotionNews info }, { full VideoNews info } ]

Для подобных задач есть более-менее "стандартные" подходы без использования JSON и т.п.... сразу скажу, все не без недостатков, IMHO.

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

Для подобных задач есть более-менее "стандартные" подходы без использования JSON и т.п.... сразу скажу, все не без недостатков, IMHO.

В голову ничего кроме создания одной единой таблички, нескольких табличек, вынесения общих полей в ещё одну табличку или использования json не приходит

больше табличек богу табличек

как насчет сделать по табличке на каждую сущность и успокоиться

придумывают себе гемор на ровном месте

Только бог табличек сломается, если будет на нескольких табличках одновременно сидеть

Не отлично, на самом деле (разве что "поля" вытаскивать в функциональные индексы). И потом получается "сейчас мы запросто напишем свою СУБД внутри вашей СУБД!". ;)

1. чем плохи функциональные индексы? 2. про свою СУБД не совесм понял

как насчет сделать по табличке на каждую сущность и успокоиться

Можно и так, иногда.

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

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

И это тоже

В голову ничего кроме создания одной единой таблички, нескольких табличек, вынесения общих полей в ещё одну табличку или использования json не приходит

Бывает ещё вариант с многими "наследниками" со ссылкой на "родительскую".

ERROR: S client not available

средствами ОРМ такое процессить - врагу не пожелаешь

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

средствами ОРМ такое процессить - врагу не пожелаешь

Спасибо. У меня орм

1. чем плохи функциональные индексы? 2. про свою СУБД не совесм понял

Они плохи тем, что это избыточный уровень абстракции: сначала засунули то, что должно было бы быть полем, в JSON, потом достаём оттуда... Кстати, засунув поле в JSON, вы тихо теряете кое-какие constraints, обычно. Т.е. это совсем не одно и то же.

я стараюсь не совать в JSONb поля, которые отвечают за целостность модели данных

Спасибо. У меня орм

Ну, что тут скажешь... что он Вам позволит, то вы и сделаете, наверное. "ORMs make easy things easier, and hard things impossible". ;)

Но вообще, а что если ряд сущностей имеют часть одинаковых полей. Например, сущность TextNews: - title - description PromotionNews: - title - description - promotion_id - image VideoNews: - title - desctiption - video И в таком духе

вот здесь вот например, едиснвтенное поле, которое стоит оговорить - это promotion_id, если не критично - его можно всунуть в JSONb и проиндексировать, в противном случае - в отдельную таблицы многие-ко-многим

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

т.к. нужны они только на выдаче резалта

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

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

Разрослась одна из таблиц, а места на диске не хватает, чтобы сделать vacuum full. Другие таблицы минимального размера. Индексы тоже ужаты. Как схлопнуть файл таблицы не используя vacuum full??

У меня такое же когда-то случилось, кластер этого не пережил

да что и говорить, пришлось ОС переустанавливать ?

запилили все через функции, на выход отдаем апликухе джейсонину с резалтом - с производительностью все стало ОК

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

я стараюсь не совать в JSONb поля, которые отвечают за целостность модели данных

А constraint-ы самих этих полей?

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

но у нас нету планов бегать в другие БД, есть несколько HL/HA проектов с базами по 100Tb

с которыми особых проблем не испытываем

А constraint-ы самих этих полей?

Ваш сорказм мне не понятен

я НЕ ХРАНЮ в JSONb атрибуты связей с другими таблицами

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

Ваш сорказм мне не понятен

Это не "сорказм", это вопрос. Т.е. было "human_weight CHECK (value>0)" (или REFERENCES), а стало?

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

Да эта "кроссплатформенность" в отношении СУБД — вообще в нетривиальных случаях пустые мечты.

Да эта "кроссплатформенность" в отношении СУБД — вообще в нетривиальных случаях пустые мечты.

это я в оправдание тем, кто начнет убером тыкать)))

Привел два сервера к идентичному состоянию. На обоих в locale -a есть одна и та же локаль ru_RU.utf8 На обоих серверах создал одну и ту же базу данных командой: createdb -e -E "UTF-8" -l "ru_RU.UTF-8" -T template0 test Затем подключился к этой базе и создал там коллате CREATE COLLATION numeric (provider = icu, locale = 'uni-u-kn-true'); В итоге результат проверки разный :( SELECT '2' < '10' COLLATE numeric; == false Что еще смотреть?

зачем вы locale смотрите? libc локали с libicu никак не связаны, смотрите версию libicu, из какого пакета вы её ставили там и там, смотрите с какими флагами она собиралась

Вот это да! Возился сутки с медленным поиском, оказалось что нужно было изменить random_page_cost с 4.0 на 2.0. Теперь он делает bitmap heap scan вместо seq scan на 6TB таблице

@blkmrkt а скорость выполнения запроса как изменилась?

@blkmrkt а скорость выполнения запроса как изменилась?

С 30 минут до 300мс

может еще кеш прогрелся пока я тестил, не знаю