Pred pol rokom - verejný do PostgreSQL.
Počas posledných mesiacov sme o ňom robili , pripravil zhrnutie na základe odporúčaní, ktoré poskytuje... ale čo je najdôležitejšie, zhromaždili sme vašu spätnú väzbu a pozreli sme sa na skutočné prípady použitia.
A teraz sme pripravení hovoriť o nových príležitostiach, ktoré môžete využiť.
Podpora rôznych formátov plánov
Plán z denníka spolu so žiadosťou
Priamo z konzoly vyberte celý blok, začínajúc od riadku s Text dopytu, so všetkými úvodnými medzerami:
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)
... a všetko skopírované vložte priamo do poľa plánu bez toho, aby ste čokoľvek oddeľovali:
Na konci dostaneme bonus k rozloženému plánu a záložka „kontext“., kde je naša žiadosť prezentovaná v celej svojej kráse:
JSON a 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
}
]"Buď s externými úvodzovkami, ako skopíruje pgAdmin, alebo bez nich - hodíme to do rovnakého poľa a výstup je krásny:
Pokročilá vizualizácia
Čas plánovania/čas vykonania
Teraz môžete lepšie vidieť, kde bol čas navyše strávený vykonávaním dotazu:
I/O časovanie
Niekedy sa musíte popasovať so situáciou, keď sa z hľadiska zdrojov zdá, že sa toho veľa nečítalo a písalo, ale čas vykonania sa zdá byť neprimerane dlhý.
Tu musíme povedať: "Ach, pravdepodobne v tom momente bol disk na serveri príliš preťažený, preto to čítanie trvalo tak dlho!"Ale nejako to nie je veľmi presné...
Ale to sa dá určiť úplne spoľahlivo. Faktom je, že medzi možnosťami konfigurácie servera PG existuje :
Umožňuje načasovanie I/O operácií. Táto možnosť je predvolene vypnutá, pretože vyžaduje neustále dopytovanie operačného systému na aktuálny čas, čo môže na niektorých platformách výrazne spomaliť výkon. Ak chcete odhadnúť náklady na časovanie na vašej platforme, môžete použiť pomôcku pg_test_timing. Vstupno-výstupné štatistiky možno získať prostredníctvom zobrazenia pg_stat_database, vo výstupe EXPLAIN (keď sa používa parameter BUFFERS) a cez pohľad pg_stat_statements.
Túto možnosť je možné povoliť aj v rámci lokálnej relácie:
SET track_io_timing = TRUE;Najlepšie na tom je, že sme sa naučili chápať a zobrazovať tieto údaje berúc do úvahy všetky transformácie stromu vykonávania:
Tu môžete vidieť, že z 0.790 ms celkového času vykonávania trvalo 0.718 ms čítanie jednej dátovej stránky, 0.044 ms jej zápis a iba 0.028 ms bolo vynaložených na všetky ostatné užitočné činnosti!
Budúcnosť s PostgreSQL 13
Nájdete tu úplný prehľad inovácií , a to konkrétne hovoríme o zmenách plánov.
Plánovacie nárazníky
Účtovanie zdrojov pridelených plánovaču sa odráža v inej oprave, ktorá nesúvisí s pg_stat_statements. EXPLAIN s možnosťou BUFFERS oznámi počet vyrovnávacích pamätí použitých počas plánovacej fázy:
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
Prírastkové triedenie
V prípadoch, keď je potrebné triedenie na mnohých kľúčoch (k1, k2, k3...), môže teraz plánovač využiť vedomosť, že dáta sú už triedené na niekoľkých z prvých kľúčov (napríklad k1 a k2). V tomto prípade nemôžete znova zoradiť všetky údaje, ale rozdeliť ich do po sebe nasledujúcich skupín s rovnakými hodnotami k1 a k2 a „pretriediť“ pomocou kľúča k3.
Celé triedenie je teda rozdelené do niekoľkých po sebe nasledujúcich druhov menších rozmerov. To znižuje množstvo potrebnej pamäte a tiež umožňuje výstup prvých údajov pred dokončením celého triedenia.
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
Vylepšenia UI/UX
Snímky obrazovky, sú všade!
Teraz je na každej karte možnosť rýchlo urobte snímku obrazovky karty do schránky celá šírka a hĺbka záložky - "pohľad" vpravo hore:
V skutočnosti väčšina obrázkov pre túto publikáciu bola získaná týmto spôsobom.
Odporúčania pre uzly
Nielenže ich pribudlo, ale o každom sa dá aj rozprávať pomocou odkazu:
Vymazanie z archívu
Niektorí ľudia skutočne požiadali o pridanie možnosti vymazať "úplne" aj plány, ktoré nie sú zverejnené v archíve - stačí kliknúť na príslušnú ikonu:
No nezabudnite, že máme , kde môžete písať svoje pripomienky a návrhy.
Zdroj: hab.com