553 вопроса по PostgreSQL с технических собеседований
553 вопроса1634 компании353 технологии
Что проверяют на интервью
Как устроена подборка
На странице собраны вопросы по PostgreSQL — от проверки базовых принципов до практического применения и архитектурных решений. В подборке чаще встречаются темы: database, sql, postgresql.
Сначала измерьте число и длительность SQL-запросов, затем устраните подтверждённый N+1 через подходящую загрузку связей. Кеширование не должно маскировать необъяснённую дорогую выборку.
Проверьте реальные строки и повторения узлов, методы сканирования и соединения, сортировки, временные файлы и buffers. Главная цель — найти, где план выполняет лишнюю работу.
Смотрите расхождение estimated и actual rows, время, loops, способ доступа и JOIN, сортировки, spills и buffers. Большая стоимость узла не равна измеренному времени выполнения.
UPDATE берёт табличную блокировку ROW EXCLUSIVE и блокирует затронутые строки, но это не запрет всех обращений к таблице. Обычные SELECT и изменения независимых строк обычно продолжаются.
В декораторе ошибочны wrap, time.now и return в finally. Нужно functools.wraps, монотонный таймер и логирование без подмены результата; декоратор должен быть определён до применения.
Начните с конкретного медленного запроса и измерений, затем изучите план, фактические строки, чтение буферов и ожидания. Меняйте только выявленное узкое место и сравнивайте результат.
Index bloat — избыточный размер индекса из-за устаревших записей и неэффективно заполненных страниц. MVCC откладывает удаление старых версий; частые изменения и задержанная очистка усугубляют рост.
Сверьте каждую цель с Makefile и фактической конфигурацией. Комментарий к migrate нельзя считать доказательством запуска тестов: название и описание противоречат друг другу.
UPDATE и DELETE оставляют старые версии строк из-за MVCC. Даже при малом числе актуальных строк таблица и индексы могут содержать много свободного или пока неочищенного пространства.
shared_buffers — общий для процессов PostgreSQL cache страниц таблиц и индексов. При обращении страницу ищут в нём, а при отсутствии загружают из файлового слоя.
User_id участвует в поиске, а name хранится как дополнительная полезная нагрузка. Это создаёт возможность index-only scan, но не гарантирует его для каждого выполнения.
Назовите измеренную конкуренцию и объясните, какой ресурс PostgreSQL упирался в предел: CPU, I/O, locks, connections или длительные транзакции. Одно число запросов без их стоимости мало что говорит.
