Это может вам IDE подставляет? вообще подстановка не должна работать в

OFFSET, Илья прав

rows, err := s.db.QueryContext(ctx, `SELECT * FROM meta_urls OFFSET $1`, 1000) Вот такое :) Из кода вызываю.

Это норм, будет работать. Это просто replacement работает:)

ну это какая-то ORM, хреен знает, что она под капотом делает вы реальные запросы к БД отлаживайте сначала а потом уже в код переносите

Delphi?

Нет там никакой ORM в pg_stats_activity запрос выглядит абсолютно так же. Да и вопрос не в подстановке или корректности запроса. А в том будет от консистентно данные в одном и том же порядке каждый раз выдавать или нет.

НЕТ

Go. То что запрос работает я проверил. А вот в консистентности его сомневаюсь. Эксперимент можнт быть просто совпадением. Потому что данных не много и они активно не меняются.

заинсертить новые данные и проверить

Лучше апдейтнуть. Порядок, без явного указания порядка, не определен. Точка. Аксиома. Обсуждению не подлежит.

Про консистентность вам ужэ всё сказали. Да это и так очевидно, на самом деле.

Порядок не определен да, он оно же берет OFFSET по какому то полю. Пускай и неявно, на уровне БД.

Проблема в кадрах. Гошников умеющие в СУБД маловато😔

Ну видите же - человек стремится. Давайте помогать. » А как определить какие первые? )) Указать ORDER BY Если это не сделать, СУБД вернет вам в таком порядке, который посчитает удобным для себя.

Действительно, сейчас проверил -- с чем-то спутал, видимо. Параметры в LIMIT работают.

Оно берёт OFFSET от того, как записи по факту пришли от исполнителя. (А приходить они могут очень по-всякому). (И это сейчас. Вот добавят ещё немного противоестественного интеллекта -- и он сам будет определять, что порядок записей неопределён, и можно отдавать n первых попавшыхся).

👍 А почему им не работать? Мы часто пагинированные запросы делаем.

На больших значениях offset начинает конкретно лагать

Это не исключает того факта, что туда можно параметризованные данные передавать, а не хардкод😊

Ну да. Но в случае выше гошка, там в int строка не пролезет

Ага. У меня на таблице с 3 000 000 000 записями оффсет на 1 000 000 000 около 20 минут бежит 🙂

Жесть. Нафига вам такое? У нас бизнес, если через 5 сек данные не получает, уже бубнить начинает😃

А если юзер может дёргать "последние" страницы пагинатора, то проду может внезапно стать плохо

504 Gateway Timeout привет шлёт

Ну вообще нам такое не надо. Это я играюсь потому что мне надо большую БД сконвертить в другую схему, без остановки сервера. т.е. обычный pg_dump кажется не подходит. Там еще по пути надо данные в некоторых полях преобразовывать. Так это это я просто дергаю Long Running Task.

А чего нельзя WHERE id > N ORDER BY id ASC LIMIT 1000? Тогда скорость выборки будет примерно одинаковой

Так переливайте пачками через select...for update skip locked

ID это URL. Текстовое поле 😂 Тока не спрашивайте какого ... Я не придумывал эту таблицу. А тот кто придумал не думал что там будет 3 000 000 000 записей и она будет весить под террабайт

Ну по нему, по идее, можно тоже сортировать

Ну первичный ключ вполне может быть не числом - это нормально

Отсортировать можно. А как больше (>) применить к строке? Чтобы по 1000 записей выбирало ? Больше последней строки из предидущей пачки? Оно точно так будет работать? Будет просто строки сравнивать побайтово?

лексикографический порядок и тд

>А как больше (>) применить к строке? Как всегда -- пишэшь > , слева одну строку, справа другую. >Оно точно так будет работать? А куда оно денется? >Будет просто строки сравнивать побайтово? Будет сравнивать в соответствии с указанным collation order. Лучшэ почитать описание строковых операторов postgres, если хотите деталей.

Более развернуто https://postgrespro.ru/docs/postgresql/14/collation

С другой стороны, если человек сам по себе порядок не важэн -- то любой сработает. Особенно если на нём pkey (если нет -- то, понятно, могут быть равные строки и просто > ужэ не обойдёшься). Ну, пока опять версия glibc не поменяется, хе-хе.