Вы представляете себе обход бинарного дерева, в котором нужно выбрать треть строчек таблицы? Он, конечно, будет быстрее полного сканирования - но гораздо больше пользы будет от индекса по какому-нибудь более различающемуся полю или сочетанию полей.
Медленнее в общем случае. Треть таблицы быстрее будет прочитать seqscan'ом.
index scan'ом читать треть таблицы - это много скакать (по памяти или random i/o) сперва для индекса, потом для каждой найденной в индексе версии строки лезть в таблицу. Много беготни. Обычно база не будет использовать такой индекс.
Melkij, запросы просто просто на выборку file_name по разным условиям. Иногда нужно делать COUNT(*).
Даты пишутся более менее последовательно по возрастанию. Про распределение данных не совсем понял.
какие именно запросы? Что такое "разные условия"?
"where status = 'pending' order by date limit 20" и всегда только pending это совсем не то же самое, что поиск по любому статусу.
под "where file_name = ?" - полностью другая история и полностью другой индекс
По распределению данных: id уникален? А file_name? уникален? Сколько из ваших 50млн строк в каком статусе типично числятся?
Обычно запросы сводятся к выбору файлов для обработки по условию:
WHERE date>= '2018' AND data <= '2020' and status = NULL LIMIT 1000
Поиск по имени файла не производится. file_name не уникален
ID НЕ уникальный.
В процессе обработки у данных статус меняется т..е. понемногу status будет из NULL превращаться в succcess. Но возможны случаи когда он будет выставлен в pending или failed
да, могли бы. Если бы не существовало частичных индексов - то сюда бы подошёл btree(status, date). Но такой индекс будет существенно больше частичного.
