вижу в этом чего-то очень плохого (если N не очень большое), и в индексе не запихано много колонок.
> где невозможно, что делать?
Где невозможно - это неприменимо очевидно :)
> Вы шутите или всё еще не поняли
Я понимаю вашу мысль. "Не стиот использовать партиции, там где это не даст прироста произвожительности или ускорения мейнтенанса."
Это как бы само по себе подразумевается.
То, что вы мне говорите про last resort - я читаю как "даже если дает прирост производительности- не используйте)."
> Не вижу в этом чего-то очень плохого (если N не очень большое), и в индексе не запихано много колонок. N = кол-ву partitions, конечно. Т.е. этот множитель добавляется ко всем запросам, которые используют подобные планы. > Где невозможно - это неприменимо очевидно :) Нет, то-то и оно. Таблицу размером в несколько терабайт партиционировать на практике придётся, скорее всего, нравится это кому-то или нет. > Я понимаю вашу мысль. Нет, не до конца Вы её понимаете, мне кажется. ;) Проще говоря, партиционирование в среднем снижает производительность запросов, это нормально и так должно быть (и это, кстати, относится не только к PostgreSQL — в других СУБД всё так же или даже ещё "хуже"!). > Не стиот использовать партиции, там где это не даст прироста произвожительности или ускорения мейнтенанса." Как будто у Вас будет какой-то выбор, в некоторых ситуациях. :( > То, что вы мне говорите про last resort И вот это Вы как раз читаете неправильно. Партиционирование для увеличения производительности на самом деле применить не так просто (и запросы, и нагрузка, и модель данных должны для этого подходить), а вот для maintenance оно подходит всегда (по крайней мере, не вижу ситуаций, когда не подходит). > Ну это да, можно и в ногу выстрелить. Ещё раз — выбора у Вас не будет, вот в чём штука.
Обсуждают сегодня