Руслан, not in на моей тестовой 9.6 с 1млн строк скатывается в hashed SubPlan и работает в полтора раза быстрее not exists nested loops. От распределения данных зависеть будет, тестировал на 0,2% пропущенных значений. И это ещё на Index Only Scan.
Быстрее может быть нарисовать merge join на plpgsql - зная, что вычитывать на самом деле надо только одну табличку прикрутить сбоку итератор и выплёвывать числа если следующий id из цикла по табличке прилетел не +1 от предыдущего. Но тоже проверять нужно, plpgsql как числодробилка ни о чём.
hx510b, так я вроде сразу написал: сначала требования к хранимке и бюджету, затем считать по прайсу сколько и каких дисков надо. Два диска по 10тб в зеркале вполне могут оказаться просто дешевле сами по себе, даже без учёта корзин, контроллеров и всего сопутствующего. Но если автор хочет именно дюжину дисков по 1тб - я могу только подивиться и пойти дальше.
Ezhyg, ну не настолько давние же, pentium dual core с маркировкой Exxxx - это всего навсего 10 лет назад, видеоядра уже в чипсете массово были (но не во всех).
Итерационно - возможно.
Итерационно для показа пользователю - да
через limit - да
offset - категорично нет. Если вы считаете, что 220к записей станет дешевле вычитывать через offset - вы не понимаете, как работает offset.
Необходимо взять последнюю полученную строку и запросить следующие 10к от неё отталкиваясь от нужного order by.
Например для postgresql это будет в корне неверное решение и ничего хорошего из этого не получится.
Сильно зависит от устройства конкретной СУБД, т.е. да - вопрос к DBA.
сложности со сложными условиями в следствии ограничений GET (в том числе и на длину в 255 символов).
это из какого RFC?
Интересуюсь потому, что в стандартах на http этого не находил, а лимиты сверху есть у конкретных реализаций: браузеров и веб-серверов.
посмотрите детали на 4 консоли или повторите команду на 2 или 3 консоли вручную. Возможно необходимо сделать специальный bios_grub раздел (parted умеет такую метку, например) или сделать отступ первого сектора раздела побольше от таблицы разделов.
там скорости передачи повыше, и могут в отличии от SATA достигать 2-3гигабит в секунду.
SATA II - это уже до 3 гбит/с на интерфейсе. SATA III - до 6гбит/с
M.2 - это до 4 линий PCI-E 3.0, чуть меньше 4 гигабайт в секунду предел, не гигабит.
Ну а дальше вопрос к контроллеру и типу нагрузки. Последовательная передача давно уже упирается в SATA интерфейс.
Быстрее может быть нарисовать merge join на plpgsql - зная, что вычитывать на самом деле надо только одну табличку прикрутить сбоку итератор и выплёвывать числа если следующий id из цикла по табличке прилетел не +1 от предыдущего. Но тоже проверять нужно, plpgsql как числодробилка ни о чём.