Вот именно teams and users это разные сущности и перемешивать их нельзя. Поэтому и нужно в таблице participants сделать два foreign key. Отдельно на users и отдельно на teams.
select company_name, poll_created_at
from
(
select company.name as company_name, poll.created_at as poll_created_at,
row_number() over (partition by company.name order by poll.created_at desc) as rn
from ...
)
where rn = 1;
1. Может быть bloating таблицы из-за изменений/удалений/втавок. Давно ли делался VACUUM, настроен ли AUTOVACUUM ?
2. Для выборки малого количества строк из таблицы полезно создать b-tree index на поле, по которому происходит фильтрация.
3. Выполняется ли периодический сбор статистики на таблице командой ANALYZE ( по плану отфильтровано 3586078 строк а выбрано ~3000, а выпишете о 10 млн) ? Неверная статистика - прямой путь к неоптимальному плану выполнения.
1. b-tree на channel_id и start кажется удачным.
2. Стоит учитывать распредление данных, но это если понимаете, как оно влияет. А так, просто возьмите да и потестируйте свои запросы на тестовой таблице.
3. Статистику не забудьте собрать.
Вы можете попробовать создать заглушки тех функций, которые вызывают проблемы. Если функции в скрипте создаются командой create or replace, то ваша заглушка будет заменена при накате.
1. Выше верно указали, что нужны агрегаты. Агрегаты могут быть частичными. Если count у вас без distinct, то показатель будет аддитивным и проблем с суммированием по агрегатам быть не должно.
2. Раз у вас таблица так растет нужно ее секционировать. Скорее всего по дате.
Может быть имеет смысл посмотреть в сторону масштабируемых СУБД, типа hbase?
Выше верно указали, что партиционирование это по сути и есть разбиение таблицы на несколько, например на помесячной основе.
Ответ написан
Комментировать
Комментировать
Оценили как «Нравится»
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.