Altı ay əvvəl - ictimai PostgreSQL-ə.
Keçən aylarda biz onun haqqında hazırladıq , xülasə hazırladı verdiyi tövsiyələrə əsaslanaraq... lakin ən əsası, rəyinizi topladıq və real istifadə hallarına baxdıq.
İndi isə istifadə edə biləcəyiniz yeni imkanlar haqqında danışmağa hazırıq.
Müxtəlif plan formatları üçün dəstək
Sorğu ilə birlikdə jurnaldan planlaşdırın
Birbaşa konsoldan, ilə xəttdən başlayaraq bütün bloku seçin Sorğu Mətni, bütün aparıcı boşluqlarla:
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)
... və kopyalanan hər şeyi heç nəyi ayırmadan birbaşa plan sahəsinə qoyun:
Sonda sökülən plana bir bonus alırıq və "kontekst" nişanı, burada sorğumuz bütün şöhrəti ilə təqdim olunur:
JSON və 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
}
]"Ya xarici sitatlarla, pgAdmin nüsxələri kimi, ya da olmadan - biz onu eyni sahəyə atırıq və nəticə gözəldir:
Qabaqcıl vizuallaşdırma
Planlaşdırma vaxtı/İcra vaxtı
İndi sorğunun yerinə yetirilməsinə əlavə vaxtın hara sərf edildiyini daha yaxşı görə bilərsiniz:
G/Ç vaxtı
Bəzən elə bir vəziyyətlə qarşılaşmalı olursan ki, resurslar baxımından çox oxunub yazılmayıb, amma icra müddəti uyğunsuz uzun görünür.
Burada demək lazımdır: "Oh, yəqin ki, o anda serverdəki disk çox yüklənmişdi, buna görə oxumaq çox vaxt apardı!"Ancaq nədənsə bu çox dəqiq deyil ...
Ancaq bu tamamilə etibarlı şəkildə müəyyən edilə bilər. Fakt budur ki, PG server konfiqurasiya seçimləri arasında var :
I/O əməliyyatlarının vaxtını təyin etməyə imkan verir. Bu seçim defolt olaraq qeyri-aktivdir, çünki o, cari vaxt üçün əməliyyat sistemini daim sorğulamağı tələb edir və bu, bəzi platformalarda performansı əhəmiyyətli dərəcədə yavaşlata bilər. Platformanızda vaxtın dəyərini qiymətləndirmək üçün pg_test_timing yardım proqramından istifadə edə bilərsiniz. I/O statistikası pg_stat_database görünüşü vasitəsilə əldə edilə bilər, EXPLAIN çıxışında (BUFFERS parametrindən istifadə edildikdə) və pg_stat_statements görünüşü vasitəsilə.
Bu seçim yerli seansda da aktivləşdirilə bilər:
SET track_io_timing = TRUE;Yaxşı, indi ən yaxşı tərəfi odur ki, icra ağacının bütün çevrilmələrini nəzərə alaraq bu məlumatları başa düşməyi və göstərməyi öyrəndik:
Burada ümumi icra müddətinin 0.790 ms-dən 0.718 ms-nin bir məlumat səhifəsini oxuduğunu, 0.044 ms-ni yazmağa sərf etdiyini və bütün digər faydalı fəaliyyətlərə yalnız 0.028 ms sərf edildiyini görə bilərsiniz!
PostgreSQL 13 ilə gələcək
Siz yeniliklərin tam icmalını tapa bilərsiniz , və biz konkret olaraq planlardakı dəyişikliklərdən danışırıq.
Planlaşdırma buferləri
Planlayıcıya ayrılmış resursların uçotu pg_stat_statements ilə əlaqəli olmayan başqa bir yamaqda əks olunur. BUFFERS seçimi ilə İZAH EDİN planlaşdırma mərhələsində istifadə olunan buferlərin sayını bildirəcək:
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
Artan çeşidləmə
Bir çox düymələr üzrə çeşidləmə lazım olduğu hallarda (k1, k2, k3...), planlaşdırıcı indi məlumatın bir neçə ilk düymədə (məsələn, k1 və k2) çeşidlənməsindən istifadə edə bilər. Bu vəziyyətdə, bütün məlumatları yenidən çeşidləyə bilməzsiniz, ancaq k1 və k2 eyni dəyərləri ilə ardıcıl qruplara bölün və k3 düyməsi ilə "yenidən çeşidləyin".
Beləliklə, bütün çeşidləmə daha kiçik ölçülü bir neçə ardıcıl növə bölünür. Bu, tələb olunan yaddaşın həcmini azaldır və həmçinin bütün çeşidləmə tamamlanmadan ilk məlumatın çıxarılmasına imkan verir.
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 təkmilləşdirmələri
Ekran görüntüləri, onlar hər yerdədir!
İndi hər nişanda tez bir fürsət var panoya nişanın ekran görüntüsünü çəkin nişanın bütün eni və dərinliyi - yuxarı sağda "görmə":
Əslində, bu nəşr üçün şəkillərin əksəriyyəti bu şəkildə əldə edilmişdir.
Düyünlər üzrə tövsiyələr
Nəinki onların sayı artıb, həm də hər biri haqqında danışa bilərsiniz linkə daxil olaraq:
Arxivdən silinir
Bəzi insanlar həqiqətən seçimi əlavə etməyi xahiş etdilər "tamamilə" silmək hətta arxivdə dərc olunmayan planlar da - lütfən, müvafiq işarəyə klikləyin:
Yaxşı, unutmayın ki, bizdə var , burada öz rəy və təkliflərinizi yaza bilərsiniz.
Mənbə: www.habr.com