Comments 13
В PostgreSQL cost — это среднее время доступа до случайной страницы в БД, поэтому по количеству костов можно посчитать время.
Но эта величина тоже не стабильная и зависит от многих параметров. Например, если диск долгое время был загружен, средняя стоимость изменится, то есть показатель снова будет необъективным.
Ребяты, стоимость (cost) — это оценка планировщика. Она никак не зависит от нагрузки на сервер, скорости работы дисков и т. п. Для одного и того же запроса стоимость может поменяться только при изменении статистики (ну или изменении настроенных параметров).
И уж конечно по оценке стоимости никак нельзя вычислить время.
"По большому счету" оценка планировщика (статистика) может вполне поменяться со временем (не только от изменения параметров DB/OS, объема данных, но и от "расположения" данных на дисках и т.п. факторов).
Не очень понимаю, что такое "по большому счету", но:
оценка планировщика и статистика — разные вещи (статистика — входная информация для оценки);
статистика никак не учитывает характеристики железа, параметры ОС, расположение данных на дисках и т. п., а учитывает только объем и особенности распределения данных (в смысле мат. статистики);
такие факторы, как соотношение времени случайного и последовательного доступа и т. п., задаются администратором с помощью конфигурационных параметров; сами по себе эти настройки никогда не меняются.
Возможно, кажется логичным, чтобы такие вещи отслеживались и учитывались автоматически, но нет: воспроизводимость и стабильность планов дороже. Про автономные/самонастраивающиеся СУБД давно говорят, но пока ни у кого хорошо не получается.
"Про автономные/самонастраивающиеся СУБД давно говорят, но пока ни у кого хорошо не получается." - компания Oracle и фактическая работа ее БД с вами не согласны... :-)
Т.е. при построении фактического плана исполнения учитывается "все что можно". Не только данные по статистике данных, но и "время отклика" и количество IO операций (причем с учетом "сколько читаем из памяти/буфера", а сколько c диска)....
Грубо говоря иногда оптимальнее/быстрее прочитать всю таблицу, чем читать ее индекс и потом данные из таблицы, а иногда наоборот...
Рад за Оракл, если им удалось добиться какого-то серьезного прогресса. Семь лет назад, когда я на нем сидел, все это было в сильно зачаточном состоянии. Правда, спрос на DBA не уменьшается, так что, боюсь, не все так гладко.
Но мы тут, вроде, про Постгрес говорили, а в нем такой автоматики в любом случае нет.
Ну видимо и по этой причине эти БД различаются...
А вот DBA нужны всегда, когда разработчики не знают/понимают (или не хотят) как принципы работы баз данных, так и специфику самих прикладных данных, они считают что "пусть база сама разрулит"... Вот (не думая) и пихают в БД свои xml и json в чистом виде (когда собственно данных там от силы 30-50%, а все остальное "обертки")... :-(
Про автономные/самонастраивающиеся СУБД давно говорят, но пока ни у кого хорошо не получается." - компания Oracle и фактическая работа ее БД с вами не согласны... :-)
Да и не только Oracle, все "большие" коммерческие СУБД в плане оптимизации запросов и автоматических подстроек под железо и текущую нагрузку, увы, на две головы впереди постгреса.
Постргес клёвый, но в нем оптимизировать все приходится вручную. Даже простейшие вещи, об оптимизации которых в Oracle или SQL Server вообще не задумываешься. А постгрес прямо с порога озадачивает вопросами про work_mem и max_connections. Ну, вон у тебя 64 гига памяти в сервере, неужели самому сложно решить, как ее разделить между пятью запросами?
Добрый день! Тут уже довольно большое обсуждение ?. Я передала ваш комментарий DBA Ивану Чувашову, эксперту из этой статьи. Ниже его ответ ⤵️
На самом деле стоимость может измеряться в произвольных единицах, определяемых параметрами планировщика (см. Подраздел 20.7.2 вот тут → https://postgrespro.ru/docs/postgresql/14/runtime-config-query. Традиционно единицей стоимости считается операция чтения страницы с диска; то есть seq_page_cost обычно равен 1.0, а другие параметры задаются относительно него. Например, в этом разделе выполняются со стандартными параметрами стоимости → https://postgrespro.ru/docs/postgresql/14/using-explain
По умолчанию эти переменные определяются относительно стоимости чтения последовательной страницы: то есть, переменную seq_page_cost удобно задать равной 1.0, а все другие переменные стоимости определить относительно неё. Но при желании можно использовать и другую шкалу, например, выразить в миллисекундах фактическое время выполнения запросов на конкретной машине.
Подкорректируйте, пожалуйста, ссылку на ютабчик
ставят
autovacuum_work_mem -1, чтобы он заимствовал
Оно так по умолчанию стоит. Формулировка оставляет желать лучшего.
В сумме может получиться 450-500 страниц — это совсем немало. Учитывая, что объем одной страницы данных — 8 килобайт.
500*8к = 4 MB, это в 2022 году действительно "немало"?
Если бы было действительно так, то запрос бы пролетал максимум за десятки миллисекунд. Но у вас там план говорит совершенно другое:
Buffers: shared hit=13937, read=149998, dirtied=125912, temp read=30325 written=30382
А буфера как раз в страницах считаются. Т.е. у вас не 450-500 страниц прочиталось, а примерно 135000 (что логично, табличка-то под гигабайт должна быть, и просканировалась вся). И ещё 30000 страниц (250 MB) временно записалось на диск.
И вот это уже действительно "немало", отсюда и 4,5 секунды на запрос.
Добрый день! Тут уже довольно большое обсуждение ?. Я передала ваш комментарий DBA Ивану Чувашову, эксперту из этой статьи. Ниже его ответ
Хороший подход. А сам то Иван не может поучавствовать или статью писал не он?
Как ускорить работу PostgreSQL с помощью конфигурации базы и оптимизации запросов