Fél éve - nyilvános a PostgreSQL-hez.
Az elmúlt hónapokban tettünk érte , összefoglalót készített az általa kiadott ajánlások alapján... de ami a legfontosabb, összegyűjtöttük visszajelzéseit, és megvizsgáltuk a valós felhasználási eseteket.
És most készen állunk, hogy beszámoljunk az új funkciókról, amelyeket használhat.
Különböző tervformátumok támogatása
Terv a naplóból, a kéréssel együtt
Közvetlenül a konzolról kiválasztjuk a teljes blokkot, a sortól kezdve Szöveg lekérdezése, minden kezdő szóközzel:
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)
... és minden másolt dolgot közvetlenül a terv mezőjébe dobjon anélkül, hogy bármit elválasztana:
A kimenetnél bónuszt is kapunk a szétszedett tervhez kontextus fül, ahol kérésünket teljes pompájában mutatják be:
JSON és 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
}
]"Még külső idézőjelekkel, pgAdmin másolatként, anélkül is - ugyanabba a mezőbe dobjuk, a kimenet szépség:
Speciális vizualizáció
Tervezési idő / végrehajtási idő
Most már jobban láthatja, hová tűnt a többletidő a lekérdezés végrehajtásakor:
I/O időzítés
Néha olyan helyzettel kell megküzdenie, amikor az erőforrásokat tekintve úgy tűnik, nem túl sokat olvastak és írtak, de úgy tűnik, hogy a végrehajtási idő valamiért nem megfelelő.
Itt kell elmondani:Ó, valószínűleg abban a pillanatban a szerveren lévő lemez túlterhelt volt, ezért tartott olyan sokáig az olvasás!"De valahogy nem túl pontos...
De abszolút megbízhatóan megállapítható. A helyzet az, hogy a PG szerver konfigurációs lehetőségei között vannak :
Lehetővé teszi az időzített I/O műveleteket. Ez a beállítás alapértelmezés szerint le van tiltva, mivel megköveteli, hogy az operációs rendszer folyamatosan lekérdezze az aktuális időt, ami egyes platformokon jelentősen lelassíthatja a dolgokat. A pg_test_timing segédprogram segítségével megbecsülheti az időzítés többletköltségét a platformon. I/O statisztikák a pg_stat_database nézeten keresztül érhetők el, az EXPLAIN kimenetben (ha a BUFFERS paramétert használjuk) és a pg_stat_statements nézeten keresztül.
Ez az opció helyi munkameneten belül is engedélyezhető:
SET track_io_timing = TRUE;Nos, most az a legjobb, hogy megtanultuk megérteni és megjeleníteni ezeket az adatokat, figyelembe véve a végrehajtási fa összes transzformációját:
Itt látható, hogy a teljes végrehajtási időből 0.790 ms-ból 0.718 ms egy oldal adat kiolvasása, 0.044 ms - megírása, és csak 0.028 ms ment minden egyéb hasznos tevékenységre!
Jövő a PostgreSQL 13-mal
Az újdonságok teljes áttekintéséért lásd: , és konkrétan a tervek változásairól beszélünk.
Tervezési pufferek
Az ütemezőhöz hozzárendelt erőforrások elszámolása egy másik javításban is megjelenik, amely nem kapcsolódik a pg_stat_statements fájlhoz. Az EXPLAIN a BUFFERS opcióval jelenti a tervezési szakaszban használt pufferek számát:
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
Növekményes rendezés
Azokban az esetekben, amikor sok kulcs (k1, k2, k3…) szerinti rendezésre van szükség, a tervező most kihasználhatja, hogy az adatok már több első kulcs (pl. k1 és k2) szerint vannak rendezve. Ebben az esetben nem rendezheti újra az összes adatot, hanem oszthatja fel egymást követő csoportokba ugyanazokkal a k1 és k2 értékekkel, és „újra rendezheti” őket a k3 kulccsal.
Így a teljes válogatás több egymást követő, kisebb méretű válogatásra bomlik. Ez csökkenti a szükséges memória mennyiségét, és lehetővé teszi az első adatok visszaadását a rendezés befejezése előtt.
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 fejlesztések
Képernyőképek mindenhol vannak!
Most minden lapon lehetőség van arra, hogy gyorsan készítsen képernyőképet a lapról a vágólapra a fül teljes szélességében és mélységében - "látvány" jobbra fent:
Valójában ehhez a kiadványhoz a legtöbb kép ilyen módon készült.
Javaslatok a csomópontokhoz
Nem csak több van belőlük, hanem mindegyikről lehet a linket követve:
Eltávolítás az archívumból
Néhányan kérték a képességet törölje az "abszolút" még az archívumban nem publikált terveket is, csak kattintson a megfelelő ikonra:
Nos, ne felejtsük el, hogy van ahol megírhatja észrevételeit és javaslatait.
Forrás: will.com