Go и pgx. Пагинация в запросах к БД Postgres

И как это решает проблему offset?

То есть если есть миллиард записей и надо выбрать первые 100 всегда будет делаться full table or index scan?

Пользователи будут очень довольны.

Много лет назад пришёл к мысли что пользователям не нужна "пагинация". Кого интересует конкретно 3я страница например?

Достаточно load N first + load more = load N starting from last ID. Если позволяет можно позволить "load all".

Никто ни разу не пришёл и не попросил страницы.

к моменту выполнения второго запроса данные могут стать неактуальными

Данные могут стать неактуальными в то время, когда результат запроса летит к пользователю. В то время, когда пользователь их читает. Собственно, для того, чтобы показывать данные, такой трюк не поменяет примерно ничего.

Да, есть ситуации, когда нужно пагинировать данные для сервиса, разбивая большую таблицу на батчи, но здесь непременное условие - не пропустить ни одной строки. По вашему алгоритму между запросами страниц может быть удалена строка из текущей страницы, после запроса которой курсор сместится на количество удалённых записей вперёд. Это касается любых алгоритмов, основанных на row_id.

некую универсальную процедуру для демаршалинга

Под демаршаллингом подразумевается маппинг данных из таблицы в поля класса?

а при чем здесь го? энивей

какие вопросы нужно задать себе, прежде чем делать пагинацию

1) правда ли нам нужно знать точное кол-во записей и страниц?

2) можем ли мы обойтись отображением первых n страниц?

3) готовы ли мы обрести беспонтовый ux порожденный limit/offset подходом?

4) понимаем ли мы, что эта штука положит базу?

5) разделяем ли передовую мысль человечества про пагинацию с помощью last_id?

Вопрос не в том - делать или не делать пагинацию. Его решили без меня. Вопрос в данном случае - как сделать проще и удобнее, раз уж требуют

Не уверен, что пагинацию через limit и offset в принципе делать правильно.

Допустим, пользуясь пагинацией через limit и offset кто-нибудь начнёт табличку целиком "постранично забирать".

Т.е. представьте, пусть у вас таблица на миллиард-десяток элементов.

пришли к вам один раз с

SELECT * FROM client_accounts WHERE <условия> LIMIT 100 OFFSET 0;

Потом пришли с

SELECT * FROM client_accounts WHERE <условия> LIMIT 100 OFFSET 100;

Пришли к вам ещё раз с

SELECT * FROM client_accounts WHERE <условия> LIMIT 100 OFFSET 200;

И т.д.

Мне кажется, или нам придётся из базы забрать n^2 строчек суммарно таким образом, чтобы читающий код мог исходные n строчек выгрести?

https://habr.com/ru/articles/301044/

Мне понравился способ из комментариев, где человек ищет по индексу (например, по идентификатору) через JOIN или временную таблицу, а далее из неё по идентификатору получает эти самые необходимые данные. Правда издержка очевидная - сам индекс.

Ну это всё прекрасно, но как и писали выше - это всё ерунда, главная проблема лимит-оффсет в производительности. Если вы делаете это в лоб, то чем дальше страница тем медленнее будет выполняться запрос.

Где-то когда-то нашел в комментариях решение, которое на удивление дает около константное время запроса на любую страницу. Концепция простая:

SELECT * FROM mega_table AS m0
INNER JOIN (
    SELECT id FROM mega_table
    WHERE <conditions>
    ORDER BY <conditions>
    LIMIT <i>
    OFFSET <j>
) AS fast_filter ON m0.id = fast_filter.id
<conditions if need>

Суть заключается в том, чтобы избежать некоторых тяжелых операции, если делаете и оффсет и условия и сортировку на одной таблице. Ну и главное, чтобы на поле id из примера был повешен индекс, а так же на те поля по которым вы подразумеваете фильтрацию и сортировку.
Хак в том, чтобы использовать только индексные поля, тем самым не заставляя БД тащить тяжелые тосты и вот это всё, а уже в самом конце, когда нам известны id выборки, то их сильно проще забрать, чем перечитывать страницы для оффсета еще и с сортировкой и условиями.

Извиняюсь если описал кривовато, но суть я думаю понятна. На боевом проекте с десятками миллионов записей, где основные данные хранятся в jsonb, а нужные для фильтров данные лежат в соседних полях с индексами - полет отличный, погрешность времени выполнения на уровне погрешности.

Копья ломаются по поводу того, что пагинация по limit/offset - плохо или вообще - пагинация зло. Но, по предложенному способу вроде замечаний особо нет )). Дело в том, что есть случаи, когда и объем и нагрузка небольшие и заказчик хочет вот простейшую пагинацию. Это мой случай как раз. ИМХО, с ума сходить не стоит и лучше сделать простейшим способом. Ну а когда/если понадобится оптимизация - тогда и будем морщить лоб )). Спасибо, коллеги!

Немного о пагинации в реальности.

https://www.amazon.com/s/ref=nb_sb_noss?url=search-alias%3Daps&field-keywords=key

Вверху страницы:

На странице 4:
145-192 of over 200,000 results for "key"
На странице 5:
193-240 of over 100,000 results for "key"

Где-то внизу плашка пагинации, там 1, 2, 3, ..., 7. Всего семь страниц на эти over дофига результатов.

Сортировка такого объёма выдачи не имеет смысла логически, я так никогда стану делать, потому что перед тем как начать пользоваться пагинацией и сортировкой я добавлю больще фильтров и уточнений запросов.

Я не понимаю ваш запрос. Он будет на каждую страницу делать либо seq scan либо index scan

Правильный запрос такой

select * from table where id > lastpage order by id limit pagesize;

Детали этого запроса оставляю за кадром

Если же у вас есть поле даты, то запрос будет пипец какой сложный, но возможный.

В общем пагинация у вас получилась для очень мелких таблиц, но рабочая.

А выяснять количество записей вообще не надо. Нет следующей страницы значит это конец. Если надо отобразить общее количество страниц, то можно быстро из индекса вытащить. Данные один чёрт будут весь сеанс меняться.

Оконные функции вас спасут. Все делается одним count(*) over () Q ,.... далее ваш запрос с ограничениями и сортировками