Před půl rokem - veřejnost do PostgreSQL.
V uplynulých měsících jsme o něm psali , připravil shrnutí na základě doporučení, která poskytuje... ale co je nejdůležitější, shromáždili jsme vaši zpětnou vazbu a podívali se na skutečné případy použití.
A nyní jsme připraveni mluvit o nových příležitostech, které můžete využít.
Podpora různých formátů plánů
Plán z protokolu spolu s požadavkem
Přímo z konzoly vyberte celý blok, počínaje řádkem s Text dotazu, se všemi úvodními mezerami:
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še zkopírované vložte přímo do pole plánu, aniž byste cokoli oddělovali:
Na konci dostaneme bonus k rozloženému plánu a záložka "kontext"., kde je naše žádost prezentována v celé své 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 uvozovkami, jak pgAdmin zkopíruje, nebo bez - hodíme to do stejného pole a výstup je krásný:
Pokročilá vizualizace
Čas plánování/čas provedení
Nyní můžete lépe vidět, kde byl další čas strávený prováděním dotazu:
I/O časování
Někdy se musíte vypořádat se situací, kdy se z hlediska zdrojů zdá, že toho nebylo příliš načteno a napsáno, ale doba realizace se zdá být nepřiměřeně dlouhá.
Zde musíme říci: "Oh, pravděpodobně v tu chvíli byl disk na serveru příliš přetížený, proto trvalo tak dlouho čtení!"Ale nějak to není moc přesné...
To se ale dá určit naprosto spolehlivě. Faktem je, že mezi možnostmi konfigurace serveru PG existuje :
Umožňuje načasování I/O operací. Tato možnost je ve výchozím nastavení zakázána, protože vyžaduje neustálé dotazování operačního systému na aktuální čas, což může na některých platformách výrazně zpomalit výkon. Chcete-li odhadnout náklady na časování na vaší platformě, můžete použít nástroj pg_test_timing. I/O statistiky lze získat prostřednictvím pohledu pg_stat_database, ve výstupu EXPLAIN (při použití parametru BUFFERS) a prostřednictvím pohledu pg_stat_statements.
Tuto možnost lze také povolit v rámci místní relace:
SET track_io_timing = TRUE;Nejlepší na tom je, že jsme se naučili rozumět a zobrazovat tato data s přihlédnutím ke všem transformacím prováděcího stromu:
Zde můžete vidět, že z 0.790 ms celkového času provádění trvalo 0.718 ms čtení jedné datové stránky, 0.044 ms její zápis a pouze 0.028 ms bylo vynaloženo na všechny ostatní užitečné činnosti!
Budoucnost s PostgreSQL 13
Najdete zde úplný přehled inovací , a to konkrétně mluvíme o změnách plánů.
Plánovací nárazníky
Účtování zdrojů přidělených plánovači se odráží v jiném patchi, který nesouvisí s pg_stat_statements. EXPLAIN s možností BUFFERS bude hlásit počet bufferů použitých během fáze plánování:
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
Přírůstkové řazení
V případech, kdy je potřeba řazení podle mnoha klíčů (k1, k2, k3...), může nyní plánovač využít znalosti, že data jsou již setříděna na několika prvních klíčích (například k1 a k2). V tomto případě nemůžete všechna data znovu seřadit, ale rozdělit je do po sobě jdoucích skupin se stejnými hodnotami k1 a k2 a „přetřídit“ pomocí klíče k3.
Celé třídění je tak rozděleno do několika po sobě jdoucích druhů menších rozměrů. To snižuje množství požadované paměti a také umožňuje výstup prvních dat před dokončením celého třídění.
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šení UI/UX
Screenshoty, jsou všude!
Nyní je na každé kartě možnost rychle pořídit snímek obrazovky karty do schránky celá šířka a hloubka záložky - "zaměřovač" vpravo nahoře:
Ve skutečnosti většina obrázků pro tuto publikaci byla získána tímto způsobem.
Doporučení pro uzly
Nejen, že jich přibylo, ale o každé se dá i mluvit pomocí odkazu:
Mazání z archivu
Někteří lidé opravdu požádali o přidání této možnosti smazat "úplně" i plány, které nejsou zveřejněny v archivu - stačí kliknout na příslušnou ikonu:
No, nezapomeňte, že máme , kam můžete psát své připomínky a návrhy.
Zdroj: www.habr.com