Все мы любим pg_basebackup за надежность, но ненавидим, когда из него нужно достать одну-единственную таблицу. Разворачивать 2 ТБ чтобы забрать 100 МБ необязательно. Я расскажу, как решить эту проблему, если у вас не хватает места, таблица нужна срочно или вы просто хотите поднять старые данные рядышком с текущей базой.

Бытует мнение, что чем детальнее статистика по данным, тем лучше планировщик PostgreSQL выбирает планы выполнения запросов. Однако у этой точности есть скрытая цена. Из доклада вы узнаете, как рост объема и детализации статистики приводит к резкому росту вычислений внутри планировщика, какие алгоритмы внутри него перестали масштабироваться и как в будущей версии PostgreSQL данный класс проблем будет устранен.

Оптимизатор запросов PostgreSQL весьма продвинут, но и он допускает ошибки. Стандартные инструменты вроде pg_stat_statements показывают лишь фактические метрики выполнения, но отнюдь не реальную оптимальность планов. Запрос, выполняющийся за 100 мс, может выглядеть быстрым, однако если планировщик ожидал 10 000 строк, а получил 100, — возможно, при правильной настройке этот запрос выполнялся бы вдесятеро быстрее, давая на масштабе значительный прирост производительности. В докладе я расскажу о pg_track_optimizer — открытом расширении, разработанном для выявления ошибок планировщика с большим разнообразием запросов. В его основе — метрики, позволяющие сравнивать ожидания планировщика и реальность, и выявлять узкие места до того, как они повлияют на систему.