and MergeAppend node types. It is not yet implemented for the ModifyTable node type, but that is likely to be changed in a future release of PostgreSQL.
последняя фраза вселяет надежду, что и этот порог скоро будет снят)
> > выбор частичного индекса затратнее
Нет, не затратнее! Потому что частичных индексов у меня, например, два (на пару последних месяцев, только по которым почти всегда выполняются запросы), а вот partitions будет столько, сколько месяцев. ;)
Согласен, хотя в том же пафмане что выбор из двух, что из тысячи - значение не имеет, правда это при прогретом кэше метаданных о секционировании. Полагаю, в будущем и в ваниле так будет.
> > что локи берутся гранулировано на те секции, которых отпрунили,
А при планировании?
я полагаю при планировании берутся SHARE UPDATE EXCLUSIVE на родительские таблицы. Может быть, я не прав, поправьте меня
> > то это удвоение особого оверхеада не несёт
Это только если считать, что к данному серверу есть только одно активное подключение. ;) Иначе — может и нести.
много *одновременных* подключений (max_connections). Больше тысячи этот параметр мало кто проставляет
> значение не имеет, правда это при прогретом кэше метаданных о секционировании. А я вот практически уверен, что имеет — там же не неонка, внутре-то. ;) > Полагаю, в будущем и в ваниле так будет. В vanilla так есть уже сейчас — при pruning используется бинарный поиск в in-memory структуре данных (тоже "кэш метаданных", практически). :) Я пишу Вам о том, что O(k) при k=2 (вот столько у меня частичных индексов!) быстрее, чем O(log(N)) при N=240 (вот столько у меня partitions, например!). ;) > Может быть, я не прав, поправьте меня Насколько я помню — нет, т.е. locks накладываются на все partitions. > много *одновременных* подключений (max_connections). Я же это и имел в виду под "активными".
Обсуждают сегодня