PostgreSQL - Leg uit

Wanneer we met databases werken, is er een punt dat het niet langer alleen gaat om het verkrijgen van de informatie die ons aangaat, maar ook om hoe we het verkrijgen, aangezien het, afhankelijk van de constructie van de query, de hoeveelheid bronnen is die onze query verbruikt, hiervoor PostgreSQL biedt ons LEG UIT een tool waarmee we zien hoe onze query wordt uitgevoerd en alles wat het vertegenwoordigt.
UITLEG en UITLEG ANALYSE
Deze twee tools vormen de belangrijkste basis bij het zoeken naar de prestatieproblemen van de query's die we uitvoeren, ondanks hun bruikbaarheid zijn ze niet iets nieuws omdat ze zijn opgenomen in PostgreSQL Sinds de beginjaren, maar dit betekent niet dat ze verouderd of verouderd zijn, integendeel, ze zijn uitgegroeid tot een tool die in staat is om de meest gedetailleerde rapporten te produceren over de uitvoering van zoekopdrachten, inclusief de resultaten die door de tool worden gegenereerd. verkregen. in formaten zoals XML of JSON voor latere analyse met andere tools.
In pgAdmin we hebben een optie beschikbaar om een ​​grafiek te krijgen van het resultaat van LEG UIT zodat we in plaats van cijfers te analyseren een grafiek kunnen zien en op deze manier gemakkelijker de problemen van de query en de mogelijkheden voor verbetering kunnen detecteren.
Verschillen tussen UITLEG en UITLEG ANALYSE
Misschien worden beide termen gebruikt alsof ze hetzelfde zijn, maar tussen hen hebben we bijvoorbeeld verschillen LEG UIT geeft ons een idee van hoe de queryplanner van plan is de query uit te voeren, maar voert deze niet uit, in plaats daarvan UITLEG ANALYSE als u het uitvoert en het geeft ons een vergelijking tussen de verwachte prestatie en de werkelijke prestatie verkregen bij de uitvoering. Bij het starten LEG UIT via pgAdmin We kunnen kiezen tussen EXPLAIN en EXPLAIN ANALYZE, wat ons het resultaat van elk zal geven als we ze selecteren
Laten we een voorbeeld bekijken van hoe deze tool te gebruiken, hiervoor gaan we gebruiken UITLEG ANALYSE, laten we de volgende code eens bekijken:

 UITLEG ANALYSE SELECTEREN left (tract_id, 5) As county_code, SUM (hispanic_or_latino) As tot, SUM (white_alone) As tot_white, SUM (coalesce (hispanic_or_latino, 0) - coalesce (white_alone, 0)) AS non_white FROM census.hisp_pop GROUP county_code ***** DOOR county_code; 

Het is een heel eenvoudige query waarbij we de velden, groeperen en rangschikken volgens een van de velden, wat we als resultaat van de prestatieanalyse zullen verkrijgen, is het volgende:

 GroupAggregate (kosten = 111.29… 151.93 rijen = 1478) (werkelijke tijd = 6.099… 10.194 rijen = 14 lussen = 1) -> Sorteren (kosten = 111.29… 114.98 rijen = 1478) (werkelijke tijd = 5.897… 6.565 rijen = 1478 lussen = 1) Sorteersleutel: ("links" ((tract_id) :: tekst, 5)) Sorteermethode: quicksort Geheugen: 136kB -> Seq Scan op hisp_pop (kosten = 0.00… 33.48 rijen = 1478) (werkelijke tijd = 0.390… 2.693 rijen = 1478 lussen = 1) Totale looptijd: 10.370 ms 

Als we een beetje moeite doen om te lezen, worden de resultaten geleidelijk gemakkelijker voor ons om te lezen, maar als we niet veel tijd hebben of als het resultaat erg uitgebreid is, kunnen we altijd de grafiek zien.

Zoals we kunnen zien, is het sneller om de resultaten op grafisch niveau te zien, het ideaal is om beide tools te gebruiken en beide gezichtspunten aan te vullen, het is dezelfde informatie alleen met verschillende hoeken, er zullen puristen zijn die alleen willen werken met de commandoconsole en dat is prima, maar een uitgebreide databaseprofessional moet alle tools gebruiken die tot zijn beschikking staan ​​om zijn werk te verbeteren.
Hiermee ronden we de tutorial af, met het gebruik van deze tools zijn we al in staat om de oorzaken te detecteren die onze zoekopdrachten niet snel maken of de mogelijkheden voor verbetering om onze zoekopdracht te optimaliseren.Vond je deze tutorial leuk en hielp je hem?Je kunt de auteur belonen door op deze knop te drukken om hem een ​​positief punt te geven