Параметр конфигурации работа mem в PostgreSQL на Linux
мне нужно оптимизировать запросы, настроив основные параметры конфигурации сервера PostgreSQL. В документации я наткнулся на
2 ответов
я опубликовал ваш план запроса на explain.depesz.com-взгляни-ка!--15-->.
оценки планировщика запросов в некоторых местах ужасно неправильные.
Вы бежали ANALYZE
в последнее время?
читать главы в руководстве по статистика, используемая планировщиком и Планировщик Константы Затрат. Обратите особое внимание на главы о random_page_cost
и default_statistics_target
.
Я бы попробовал:
ALTER TABLE diplomas ALTER COLUMN number SET STATISTICS 1000;
ANALYZE diplomas;
учитывая ваши строки 10M вы может, даже выше. Это зависит от распределения ваших данных и запрос. Эксперимент. По умолчанию-100, Макс. это 10000.
для базы данных такого размера, только 1 или 5 Мб work_mem
как правило, недостаточно. Прочтите страница Вики Postgres по настройке Postgres что @aleroot связан С.
как ваш запрос должен 430104kB памяти на диске по данным EXPLAIN
выход, вы должны установить work_mem
что-то вроде 500 МБ или больше, чтобы разрешить сортировку в памяти. Для представления данных в памяти требуется больше места, чем для представления на диске. Вам может быть интересно, что том Лейн опубликовал по этому вопросу недавно.
повышение work_mem
просто немного, как вы пытались, не поможет много или даже может замедлиться, по-видимому. Не знаю, как объяснить замедление. Может быть, дополнительные work_mem
не используется вообще или только изначально, будучи недостаточно, но принимает вдали от других выделений памяти.
если ваша память ограничена, не устанавливайте work_mem
слишком высоко, или вы можете голодать конкурирующих ресурсов. Только установите его достаточно высоко временно для этого запроса:
SET work_mem = '500MB';
после этого сбросьте его по умолчанию:
RESET work_mem;
или, еще лучше, использовать SET LOCAL
установить его только для текущей транзакции. Лучше запустить все это в одной транзакции в любом случае.
SET search_path='tmp';
-- Generate some data ...
-- DROP table tmp.table_name ;
-- CREATE table tmp.table_name ( n INTEGER NOT NULL PRIMARY KEY);
-- INSERT INTO tmp.table_name(n) SELECT generate_series(1,1000);
-- DELETE FROM tmp.table_name WHERE random() < 0.05 ;
на за исключением запрос эквивалентен следующему НЕ СУЩЕСТВУЕТ форма, которая генерирует другой план запроса ( но те же результаты) здесь (9.0.1 beta something)
-- EXPLAIN ANALYZE
WITH q1 AS (
SELECT 1+tn.n AS n
FROM table_name tn
WHERE NOT EXISTS (
SELECT * FROM table_name nx
WHERE nx.n = tn.n+1
)
)
SELECT q1.n
FROM q1
ORDER BY q1.n DESC;
(версия с рекурсивным CTE также может быть возможна : -)
EDIT: планы запросов. все для 100к записей с 0,2 % удалены
исходный запрос:
------------------------------------------------------------------------------------------------------------------------------------------
Sort (cost=36461.76..36711.20 rows=99778 width=4) (actual time=2682.600..2682.917 rows=222 loops=1)
Sort Key: q1.n
Sort Method: quicksort Memory: 22kB
-> Subquery Scan q1 (cost=24984.41..26979.97 rows=99778 width=4) (actual time=2003.047..2682.036 rows=222 loops=1)
-> SetOp Except (cost=24984.41..25982.19 rows=99778 width=4) (actual time=2003.042..2681.389 rows=222 loops=1)
-> Sort (cost=24984.41..25483.30 rows=199556 width=4) (actual time=2002.584..2368.963 rows=199556 loops=1)
Sort Key: "*SELECT* 1".n
Sort Method: external merge Disk: 3512kB
-> Append (cost=0.00..5026.57 rows=199556 width=4) (actual time=0.071..1452.838 rows=199556 loops=1)
-> Subquery Scan "*SELECT* 1" (cost=0.00..2638.01 rows=99778 width=4) (actual time=0.067..470.652 rows=99778 loops=1)
-> Seq Scan on table_name (cost=0.00..1640.22 rows=99778 width=4) (actual time=0.063..178.365 rows=99778 loops=1)
-> Subquery Scan "*SELECT* 2" (cost=0.00..2388.56 rows=99778 width=4) (actual time=0.014..429.224 rows=99778 loops=1)
-> Seq Scan on table_name (cost=0.00..1390.78 rows=99778 width=4) (actual time=0.011..143.320 rows=99778 loops=1)
Total runtime: 2684.840 ms
(14 rows)
не существует-версия с CTE:
----------------------------------------------------------------------------------------------------------------------
Sort (cost=6394.60..6394.60 rows=1 width=4) (actual time=699.190..699.498 rows=222 loops=1)
Sort Key: q1.n
Sort Method: quicksort Memory: 22kB
CTE q1
-> Hash Anti Join (cost=2980.01..6394.57 rows=1 width=4) (actual time=312.262..697.985 rows=222 loops=1)
Hash Cond: ((tn.n + 1) = nx.n)
-> Seq Scan on table_name tn (cost=0.00..1390.78 rows=99778 width=4) (actual time=0.013..143.210 rows=99778 loops=1)
-> Hash (cost=1390.78..1390.78 rows=99778 width=4) (actual time=309.923..309.923 rows=99778 loops=1)
-> Seq Scan on table_name nx (cost=0.00..1390.78 rows=99778 width=4) (actual time=0.007..144.102 rows=99778 loops=1)
-> CTE Scan on q1 (cost=0.00..0.02 rows=1 width=4) (actual time=312.270..698.742 rows=222 loops=1)
Total runtime: 700.040 ms
(11 rows)
не Существует-версия без CTE
--------------------------------------------------------------------------------------------------------------------------------------
Sort (cost=6394.58..6394.58 rows=1 width=4) (actual time=692.313..692.625 rows=222 loops=1)
Sort Key: ((1 + tn.n))
Sort Method: quicksort Memory: 22kB
-> Hash Anti Join (cost=2980.01..6394.57 rows=1 width=4) (actual time=308.046..691.849 rows=222 loops=1)
Hash Cond: ((tn.n + 1) = nx.n)
-> Seq Scan on table_name tn (cost=0.00..1390.78 rows=99778 width=4) (actual time=0.014..142.781 rows=99778 loops=1)
-> Hash (cost=1390.78..1390.78 rows=99778 width=4) (actual time=305.732..305.732 rows=99778 loops=1)
-> Seq Scan on table_name nx (cost=0.00..1390.78 rows=99778 width=4) (actual time=0.007..143.783 rows=99778 loops=1)
Total runtime: 693.139 ms
(9 rows)
мой вывод заключается в том, что версии" не существует " заставляют postgres создавать лучшие планы.