БГ
между конфами и сообщениями нет M2M, просто связь через ещё одну талицу
Size: a a a
2021 July 03
VN
это же плохо, дополнительные тормоза. А сколько конференций должна выдерживать база?
VN
твой запрос сейчас в худшем случае будет выдавать колво строк, равное количеству всех конференций - ты их все собрался потреблять из постгреса?
БГ
там за экраном остался лимит с оффсетом, в этом плане всё нормально)
БГ
Это проект пока что +/- для себя, так что чем больше тем лучше
БГ
тормоза тормозами, а архитектура так выходит более удобная
SA
Да, это я упустил, извини. Вот:
class OwnerCat(pw.Model):
owner = pw.ForeignKeyField(Owner)
cat = pw.ForeignKeyField(Cat)БГ
Тем более что я сомневаюсь что прям чудовищные тормоза от одного джоина возникнут
Зато в обмен - нормальная форма, избегание дублирования, плюшечки)
Зато в обмен - нормальная форма, избегание дублирования, плюшечки)
VN
тороза будут от group by
VN
лучше както так
select *
from (
select converence as hot_conference_id, max(message) as last_message_id
from (
select conference, message
from conference_messages
order by message_id desc
limit 100000 -- думаю столько не жалко потратить на seqscan
) _
group by conference
) __
join messages m on m.id = last_message_id;
create index on conference_messages (message_id desc);
VN
но если между активными конфами будет сильный разброс по колву сообщений, то самая активная конфа будет вытеснять осталные конфы из выборки
БГ
это практически то же что есть
у меня как бы вопрос в том что мне надо от максимального месседжа соответствующее ему поле sender выловить
у меня как бы вопрос в том что мне надо от максимального месседжа соответствующее ему поле sender выловить
VN
разница в том, что в твоем запросе всегда будет делаться полный проход по таблице conference_messages. А в моем варианте проход делается только по верхушке таблицы
БГ
это вообще не принципиально сейчас)
VN
когда тебе предложили оконную функцию, то ты сказал что производительность важна
БГ
она важна, но только если какие-то совсем большие расхождения будут, типа раз в 10 по производительности
БГ
наверное всё же сделаю на оконной функции, оно читается как-то проще
VN
оконная функцию думаю хуже, она вообще наверно будет всю таблицу conference_messages копировать во временную таблицу (а в оперативку петпроджекта она влазить быстро перестанет) изза чего возрастет io с диском
БГ
Ну вот получается два стула - оконная функция или подзапрос с джойном
БГ
Хоть монетку бросай)