offset, если в обоих случаях нам понадобится сортировка по индексированным полям?
Обе пагинации будут работать медленно, если сортировка с сортировочным индексом не совпадает.. или я не прав?
(кстати, поля по которым возможна сортировка - их всегда индексируют?)
Курсорная пагинация работает лучше если в начало списка добавляются новые элементы
Это нужно в сценариях, когда быстро появляются данные. А по скорости, я так понимаю, отличий нет? (ну, если не считать старые бд, где offset не оптимизирован под сортировочный индекс)
Разве offset все равно поднимает данные, которые надо пропустить?
Что вы считаете "старыми", постгрес например старый?
Согласен, не совсем корректно выразился) p.s.: в постгресе, кстати, если не ошибаюсь, оптимизацию для offset только в 18 году завезли
И всё ещё OFFSET 1000000 будет дорог
В какой бд и из-за чего? Сортировочный индекс совпадает -> бинарный поиск
в PG за счёт того, что ему всё ещё нужно промотать N записей (данные о которых могут лежать в кэшах, а может и на диске), проверить видимость строк (и хорошо, если данные давно не трогали и сработают всякие оптимизации). Так что работы в худшем случае всё равно O(N), хотя и быстрее чем сексканить. Как гласит дока: "The rows skipped by an OFFSET clause still have to be computed inside the server; therefore a large OFFSET might be inefficient."
А курсор помогает избежать этой лотереи, правильно понимаю? (но там все равно нужно, чтобы сортировка с сортировочным индексом совпадала)
Если вы под "курсором" понимаете передачу начальной позиции через условие (SELECT * FROM table WHERE field>$last_value LIMIT 100) , то да, вы находите по индексу нужную позицию относительно быстро, без гарантий, что пропустите заданное количество записей, а дальше отбираете и проверяете обычно небольшой LIMIT записей.
Стикер
Обсуждают сегодня