потому что они подходят под фильтр)
все данные - нужные

для чего нужные, я же спрашиваю! глазами смотреть?

прямо здесь и сейчас?

да.

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

Получается из pg_shadow уже ни чего не пропишешь и только новый пароль.

влияет ли порядок выборки на скорость
WHERE szDate >= FORMAT_DATE("%Y%m%d", CURRENT_DATE - EXTRACT(DAY FROM (CURRENT_DATE)))
 AND a4.cust_no IS NULL
 AND lRetailStoreID <> 303
допустим 1_000_000 из них 100_000 is null
a4.cust_no IS NULL
может это условие должны идти первым?

Статья бесполезная, но, кажется, дошло. Это анонимная память процесса, причём shared между остальными.
Обычно я привык к hugepages, а тут вот так.

ваш сервер с бизнес логикой сможет сразу переворить 14 милионов записей?

ну если другой вопрос то тяните 14 млн. завтра будет 100 млн, и вы и их будете тянуть. идите в магазин за ssd

ну окей. завтра будет 100 млн.
данные, уникальные. и как быть то с этим всем?
к примеру, есть 100 млн. человек. система должна выбрать их всех и как-то обработать.
как в такой ситуации быть?

лол, так я спрашиваю уже в 5 раз, в чем заключается обработка?

Выбирать курсорами. Зачем вам 100 миллионов тянуть в память?

супер. уже что-то. не знал про них. сейчас почитаю. спасибо

Что значит "обработать"?  Они как-то друг с другом связаны, при обработке одного вам могут понадобиться данные другого?  Если нет - то обрабатывайте их последовательно, пачками по миллиону например, или как вам там удобно. Если да - то либо переносить логику обработки ближе к данным (т.е. обрабатывать прямо в БД хранимками) либо всё таки тащить все целиком.

> при таком запросе очень нагружается cpu и i/o.

Хмм... а Вы чего ожидали, извините? Что PostgreSQL возьмёт данные из воздуха (прочитать-то их нужно, правда)? ;)

> поможет ли limit в данной ситуации?

У Вас и проблемы-то нет, по-моему. Чтобы выдать данные как можно быстрее, PostgreSQL использует имеющиеся ресурсы, и это нормально. Вы, что, хотите, чтобы всё работало помедленнее (а disk, CPU и RAM в этот сервер вставлены для того, чтобы ими любоваться?). ;)

Кроме шуток, лучшего по производительности, чем с index-only scan, тут не добьёшься.
Если Вам почему-то нужно экономить ресурсы — сам PostgreSQL таким не занимается, нужно что-то внешнее (но зачем?!).

Порядок условий в WHERE не имеет значения, в общем-то.

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

всё целиком не обязательно тащить. для порционной выборки подойдут  только курсоры?

секционирование и разбитие на несколько параллельных процессов например

Я бы сделал условие вида id > N и LIMIT добавил. N увеличивал бы на каждой итерации