Сейчас посчитаю процент удалённых - это не быстро.

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

Ну а как тут база сделает по другому? Если есть 100500 разных значений поля deleted - ей придётся по любому все эти значения хранить в индексе. А это минимум 64-битные числа в моём случае.

Разве это оптимально хранить их там?

По скорости моё решение точно не медленнее должно быть. Но зато есть выигрыш в размере индекса.

А ты проверь...
И так при добавлении / обновлении записи, тебе прийдется уже ДВА индекса менять.
Например в постгерссе, если у тебя записей меньше чем сотня или они убираются в десяток страниц, то индекс ВО ВСЕХ случаях вреден.

Почему вреден? Планировщик же просто не будет его использовать. Или в смысле что память ест и какой-то оверхэд на инсерты?

При добавлении - только один индекс будет меняться. Оба индекса будут меняться только в случае "удаления" объекта в корзину или его восстановления - это не очень частые операции по сравнению с добавлением.

У меня хуелярды записей, поэтому даже небольшая экономия на размере индекса может сказаться положительно. 😊

Уже 20 минут идёт фулл-скан базы с двумя шардами, что бы посчитать сколько же у меня удалённых объектов  в ней 😊

12% записей в базе - это удалённые.

Хм, ну ладно, не лярды у меня, а всего то 130млн.

Последовательное сканирование во много раз быстрее индексного. Планировщик попытается использовать индекс (там решение применяется в зависимости от констант из конфига).
Плюс постгря должен еще проверить что найденная строчка, не удалена и видима для запроса. В индексах этой инфы нет, и получаются лишние переходы в памяти (забивает кэш лишнего, внутренние локи на структуры и тд..).
Ну и оверхед на вставке с индексами. Кстати он достаточно существенен, особенно если строчки тяжелые.

ну тогда удали поле deleted из индекса... И индекс будет меньше и при изменениях ничего перестраиваться не будет

Ну вот я и хотел его удалить за счёт "частичных индексов". Но монга не дала - говорит не могу два индекса с одинаковым набором полей и разными опциями. Условие для "частичного индекса" считается "опцией" в монге.

Или ты имеешь ввиду, что вообще его не индексировать ни как - пускай сканом отфильтрует удалённые?

ну так попробуй не заморачиваться с этим полем и условиями.

причем тут фулскан. У тебя в 90% случаев будет одна запись. В 10% (а то и меньше) будет две три записи, которые удалены. Монга их просмотрит и исключит из ответа..

У нас просто вполне может быть что у конктерного юзера могжет быть другая пропорция. Например 90% удалёных, и 10% живых.

И ещё нужна функция "покажи сколько всего у меня живых объектов". А это превратится в фулскан всех объектов юзера, что бы выдать одну циферку.