А я правильно понимаю, что меня отговарили от системы 1

канал - 1 таблица, потому что СУБД автоматически сожмёт одинаковые ключи (id каналов)? Потому что я иначе вообще не вижу экономии места.

1 канал чего?

создайте одну таблицу, сделайте партицирование по id/названию канала и не парьтесь. Создаваю кучу таблиц вы раздуваете системные каталоги, это не есть хорошо

Сервиса. В нём много каналов. Раньше я делал структуру, когда таблицы каждого канала были как-то так: sql CREATE TABLE channels.users_<ID КАНАЛА> ( ... ) CREATE TABLE channels.messages_<ID КАНАЛА> ( ... ) И запросы делал через EXECUTE и форматы. Но мне сказали что это бредовая архитектура (из-за каких-то правил). Я сел её перерабатывать, когда ID каналов выносятся в отдельный столбец вместо названия таблицы. Ну послушал. Но не понял сути, разве что облегчения работы.

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

По-этому я и не понял экономии. Разве что мой ***изм с форматами больной перестал быть нужен.

Не надо ругаться. Хоть эту шифровку я и не смог расшифровать.

На какой сотне тысяч таблиц пг скажет прощай ?

Ну хз-хз. По сути, не должно вообще.

просто хочу напомнить про jsonb, вдруг поможет...

Тоже знаю, пытался применить, но не представляю, где он мне может пригодится именно в данном вопросе.

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

> мне сказали что это бредовая архитектура Потому что это совершенно бредовая архитектура. > а (из-за каких-то правил) Я ещё Вам могу сказать, что архитектура, которая предполагает, что 10*10=17, бредовая. Из-за "правила", что 10*10=100. Понимаете, к чему я веду? ;) Так вот, реляционные БД тоже основаны на соответствующей теории (вообще, RDBMS созданы не ради какой-то идиотской экономии на битах). И в том числе существует формальная теория проектирования их схем, поэтому channels.users_<ID КАНАЛА> — это примерно так же "гениально", как 10*10=17. > Но не понял сути, Так почему бы Вам не почитать любой учебник по реляционным СУ(БД)? > разве что облегчения работы. Это одна из целей, да.

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

1 > Я ничего не отрицаю. Я в этом не разбираюсь, поэтому и спрашивал 2 > Ещё раз повторюсь. Я этого не знал. Мне показалось логичным выносить ID канала в название таблицы, поскольку это статичное долгоиграющее значение.

ну опиши веселье в двух словах в этом чате)))

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

Кому надо — найдёт (и принесёт сюда ссылку). Мне не надо. ;)

всмысле клиентский код?

Серверный бэкэнд.

Ну что у него там работает с базой

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

Телеграмм на максималках.

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

Тогда у меня последовательности полететь вроде как должны...

а вообще хайлоад без кафки не бывает 🤔

Я один ничего не понял?

Натса

ALTER TABLE ATTACH PARTITION без блокировки появилось в 12 версии, так что с точки зрения highload до 12 версии ваше решение лучше чем партицирование встроенными средствами

Ну с учётом что половина моего результата это работа GPT.