Для плановой замены на более большие диски вероятно лучше подойдёт вот это сочинение: https://ru.stackoverflow.com/a/637847/203622
Обычно не проблема одновременно воткнуть все 4 диска.
Также учитывайте, что текст свыше 255 символов занимает L+2 байта.
И внимание на многобайтовые кодировки.
Число в скобках у varchar - число символов. Предел же в 64 килоБАЙТа. Что далеко не всегда одно и то же. Для utf8mb4 вы гипотетически сможете записать от 16к до 65к символов - в зависимости от того, что именно пишете.
Ну и конкретно для varchar важнейшая деталь - 64кб - это не его предельный размер. Это hardcoded лимит на размер одной строки таблицы, включающий в себя все колонки этой таблицы. Невозможно иметь два varchar по 40кб
если есть то какого типа (уникальный, кластерный)?
primary key, btree.
есть много свободной оперативки для построения хэш таблицы.
Не учитывается планировщиком. Есть work_mem - влезаем - берём его. Нет делаем disksort. Дисковой сортировки не было. hash join вовсе не умеет temp files и всегда в памяти. Если планировщик считает, что не влезет в work_mem - то предпочитает другой план.
Руслан, вы про какую-то другую СУБД. Нет в postgresql никакого tempdb, тем более разделяемого по кластеру между пользователями в оперативке. work_mem выделяется динамически в приватной памяти каждого отдельного backend под каждый отдельный того требующий узел плана запроса.
быстрее чем с диском (хотя если диск SSD то разница не сильно большая).
О да, разница всего лишь порядками измеряется.
Выше я забыл дописать - 100% cache hit по shared buffers. С дисков не читалось ничего и not in оказался всё равно в полтора раза быстрее. Потому что миллион index lookup всё равно имеют свою цену. И это на index only scan, т.е. для проверки mvcc мы страницы таблички не поднимали.
Запрос с except у меня получается посередине по скорости. А чисто алгоритмически - сюда бы неплохо merge join встал, о чём уже упоминал. Одну табличку читать по индексу уже отсортированную, опорную последовательность мы заранее может гарантировать последовательность значений. То есть на сортировку ресурсов не тратим вовсе.
Руслан, 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 умеет такую метку, например) или сделать отступ первого сектора раздела побольше от таблицы разделов.
Обычно не проблема одновременно воткнуть все 4 диска.