Een half jaar geleden - openbaar naar PostgreSQL.
De afgelopen maanden hebben we over hem gedaan , maakte een samenvatting op basis van de aanbevelingen die het geeft ... maar het belangrijkste is dat we uw feedback hebben verzameld en naar echte gebruiksscenario's hebben gekeken.
En nu zijn we klaar om u te vertellen over de nieuwe functies die u kunt gebruiken.
Ondersteuning voor verschillende planformaten
Plan vanuit het logboek, samen met het verzoek
Direct vanaf de console selecteren we het hele blok, beginnend bij de regel met Vraag tekst, met alle voorloopspaties:
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)
... en gooi alles wat gekopieerd is direct in het veld voor het plan, zonder iets te scheiden:
Bij de uitvoer krijgen we ook een bonus voor het gedemonteerde plan context-tabblad, waar ons verzoek in al zijn glorie wordt gepresenteerd:
JSON en 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
}
]"Zelfs met externe aanhalingstekens, zoals pgAdmin kopieert, zelfs zonder - we gooien in hetzelfde veld, de uitvoer is prachtig:
Geavanceerde visualisatie
Planningstijd / uitvoeringstijd
Nu kunt u beter zien waar de extra tijd is gebleven bij het uitvoeren van de query:
I/O-timing
Soms heb je te maken met een situatie waarin, in termen van middelen, het lijkt alsof er niet te veel is gelezen en geschreven, maar het lijkt erop dat de uitvoeringstijd om de een of andere reden onlogisch lang is.
Hier moet gezegd worden:Oh, waarschijnlijk was op dat moment de schijf op de server te overbelast, daarom duurde het zo lang om te lezen!"Maar op de een of andere manier is het niet erg nauwkeurig...
Maar het kan absoluut betrouwbaar worden bepaald. Het feit is dat er onder de configuratie-opties van de PG-server zijn :
Maakt getimede I/O-bewerkingen mogelijk. Deze instelling is standaard uitgeschakeld, omdat het besturingssysteem constant de huidige tijd moet opvragen, wat op sommige platforms aanzienlijk kan vertragen. U kunt het hulpprogramma pg_test_timing gebruiken om de overhead van timing op uw platform te schatten. I/O-statistieken kunnen worden verkregen via de weergave pg_stat_database, in de EXPLAIN-uitgang (wanneer de parameter BUFFERS wordt gebruikt) en via de weergave pg_stat_statements.
Deze optie kan ook worden ingeschakeld binnen een lokale sessie:
SET track_io_timing = TRUE;Welnu, het beste is dat we hebben geleerd deze gegevens te begrijpen en weer te geven, rekening houdend met alle transformaties van de uitvoeringsboom:
Hier kunt u zien dat van de 0.790 ms van de totale uitvoeringstijd, 0.718 ms nodig was om één pagina met gegevens te lezen, 0.044 ms om het te schrijven, en slechts 0.028 ms werd besteed aan alle andere nuttige activiteiten!
Toekomst met PostgreSQL 13
Zie voor een volledig overzicht van wat er nieuw is , en dan hebben we het specifiek over wijzigingen in plannen.
Buffers plannen
Rekening houden met middelen die zijn toegewezen aan de planner wordt weerspiegeld in een andere patch die niet gerelateerd is aan pg_stat_statements. EXPLAIN met de optie BUFFERS rapporteert het aantal gebruikte buffers tijdens de planningsfase:
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
Incrementeel sorteren
In gevallen waarin sorteren op veel sleutels (k1, k2, k3...) nodig is, kan de planner nu profiteren van de wetenschap dat de gegevens al zijn gesorteerd op verschillende van de eerste sleutels (bijv. k1 en k2). In dit geval kunt u niet alle gegevens opnieuw sorteren, maar ze verdelen in opeenvolgende groepen met dezelfde waarden van k1 en k2, en ze "opnieuw sorteren" met de sleutel k3.
Zo valt de hele sortering uiteen in meerdere opeenvolgende sorteringen van kleinere omvang. Dit vermindert de benodigde hoeveelheid geheugen en stelt u ook in staat om de eerste gegevens te retourneren voordat het sorteren is voltooid.
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-verbeteringen
Screenshots zijn overal!
Nu is er op elk tabblad een mogelijkheid om snel maak een screenshot van het tabblad naar het klembord voor de gehele breedte en diepte van de tab - "zicht" rechtsboven:
Eigenlijk zijn de meeste foto's voor deze publicatie op deze manier verkregen.
Aanbevelingen over knooppunten
Er zijn er niet alleen meer, maar ongeveer elke die je kunt door de link te volgen:
Verwijderen uit het archief
Sommigen hebben om de mogelijkheid gevraagd verwijder "absoluut" zelfs plannen die niet in het archief zijn gepubliceerd - klik gewoon op het overeenkomstige pictogram:
Nou, laten we niet vergeten dat we dat hebben waar u uw opmerkingen en suggesties kunt schrijven.
Bron: www.habr.com