Преди половин година - публичен към PostgreSQL.
През последните месеци направихме нещо за него , подготви резюме въз основа на препоръките, които дава... но най-важното е, че събрахме вашите отзиви и разгледахме реални случаи на употреба.
И сега сме готови да ви разкажем за новите функции, които можете да използвате.
Поддръжка на различни формати на планове
Планирайте от дневника, заедно със заявката
Директно от конзолата избираме целия блок, започвайки от реда с Текст на заявката, с всички водещи интервали:
Query Text: INSERT INTO dicquery_20200604 VALUES ($1.*) ON CONFLICT (query)
DO NOTHING;
Insert on dicquery_20200604 (cost=0.00..0.05 rows=1 width=52) (actual time=40.376..40.376 rows=0 loops=1)
Conflict Resolution: NOTHING
Conflict Arbiter Indexes: dicquery_20200604_pkey
Tuples Inserted: 1
Conflicting Tuples: 0
Buffers: shared hit=9 read=1 dirtied=1
-> Result (cost=0.00..0.05 rows=1 width=52) (actual time=0.001..0.001 rows=1 loops=1)
... и хвърлете всичко копирано директно в полето за плана, без да разделяте нищо:
На изхода получаваме и бонус към разглобения план контекстен раздел, където нашата молба е представена в целия й блясък:
JSON и YAML
EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON)
SELECT * FROM pg_class;"[
{
"Plan": {
"Node Type": "Seq Scan",
"Parallel Aware": false,
"Relation Name": "pg_class",
"Alias": "pg_class",
"Startup Cost": 0.00,
"Total Cost": 1336.20,
"Plan Rows": 13804,
"Plan Width": 539,
"Actual Startup Time": 0.006,
"Actual Total Time": 1.838,
"Actual Rows": 10266,
"Actual Loops": 1,
"Shared Hit Blocks": 646,
"Shared Read Blocks": 0,
"Shared Dirtied Blocks": 0,
"Shared Written Blocks": 0,
"Local Hit Blocks": 0,
"Local Read Blocks": 0,
"Local Dirtied Blocks": 0,
"Local Written Blocks": 0,
"Temp Read Blocks": 0,
"Temp Written Blocks": 0
},
"Planning Time": 5.135,
"Triggers": [
],
"Execution Time": 2.389
}
]"Дори и с външни кавички, като pgAdmin копия, дори и без - хвърляме в същото поле, изходът е красота:
Разширена визуализация
Време за планиране/време за изпълнение
Сега можете по-добре да видите къде е отишло допълнителното време при изпълнение на заявката:
I/O време
Понякога трябва да се справите със ситуация, в която по отношение на ресурсите изглежда, че не е прочетено и написано твърде много, но изглежда, че времето за изпълнение е неразбираемо голямо по някаква причина.
Тук трябва да се каже:О, вероятно в този момент дискът на сървъра е бил твърде претоварен, затова е отнело толкова време за четене!„Но някак не е много точно...
Но може да се определи абсолютно достоверно. Факт е, че сред опциите за конфигуриране на PG сървъра има :
Разрешава времеви I/O операции. Тази настройка е деактивирана по подразбиране, тъй като изисква от операционната система постоянно да прави заявки за текущия час, което може да забави значително нещата на някои платформи. Можете да използвате помощната програма pg_test_timing, за да оцените режийните разходи за време на вашата платформа. I/O статистика може да бъде получена чрез изгледа pg_stat_database, в изхода EXPLAIN (когато се използва параметърът BUFFERS) и през изгледа pg_stat_statements.
Тази опция може да бъде активирана и в рамките на локална сесия:
SET track_io_timing = TRUE;Е, сега най-добрата част е, че се научихме да разбираме и показваме тези данни, като вземаме предвид всички трансформации на дървото за изпълнение:
Тук можете да видите, че от 0.790 ms от общото време за изпълнение, 0.718 ms са отнели четене на една страница с данни, 0.044 ms - писане и само 0.028 ms са изразходвани за всички други полезни дейности!
Бъдеще с PostgreSQL 13
За пълен преглед на новостите вижте , като конкретно говорим за промени в плановете.
Планиране на буфери
Отчитането на ресурсите, разпределени към планировчика, е отразено в друга корекция, която не е свързана с pg_stat_statements. EXPLAIN с опцията BUFFERS ще отчете броя на буферите, използвани по време на фазата на планиране:
Seq Scan on pg_class (actual rows=386 loops=1) Buffers: shared hit=9 read=4 Planning Time: 0.782 ms Buffers: shared hit=103 read=11 Execution Time: 0.219 ms
Инкрементално сортиране
В случаите, когато е необходимо сортиране по много ключове (k1, k2, k3…), планиращият вече може да се възползва от знанието, че данните вече са сортирани по няколко от първите ключове (напр. k1 и k2). В този случай не можете да пресортирате отново всички данни, а да ги разделите на последователни групи с еднакви стойности на k1 и k2 и да ги „пресортирате“ по ключа k3.
Така цялото сортиране се разпада на няколко последователни сортирания с по-малък размер. Това намалява необходимото количество памет и също така ви позволява да върнете първите данни, преди цялото сортиране да приключи.
Incremental Sort (actual rows=2949857 loops=1) Sort Key: ticket_no, passenger_id Presorted Key: ticket_no Full-sort Groups: 92184 Sort Method: quicksort Memory: avg=31kB peak=31kB -> Index Scan using tickets_pkey on tickets (actual rows=2949857 loops=1) Planning Time: 2.137 ms Execution Time: 2230.019 ms
UI/UX подобрения
Екранните снимки са навсякъде!
Сега във всеки раздел има възможност за бързо направете екранна снимка на раздела в клипборда за цялата ширина и дълбочина на раздела - "гледка" дясно-горе:
Всъщност по-голямата част от снимките за тази публикация са получени по този начин.
Препоръки за възел
Има не само повече от тях, но за всеки един можете като следвате линка:
Премахване от архива
Някои поискаха способността да изтрий "абсолютно" дори планове, които не са публикувани в архива - моля, просто щракнете върху съответната икона:
Е, нека не забравяме, че имаме където можете да пишете вашите коментари и предложения.
Източник: www.habr.com