Identifiera frågebearbetningskomponenterna

  • 7 minuter

Det finns fyra separata steg för att köra frågan. I körningsordningen är följande steg:

  1. Parsning
  2. Transformering (skrivmaskin)
  3. Planerad
  4. Körnings-

Parsern

Parsern ansvarar för att kontrollera frågesträngen efter giltig syntax. Parsern har två huvuddelar:

  • gram.y som består av en uppsättning grammatikregler och motsvarande åtgärder.
  • scan.1 lexer, som identifierar identifierare och SQL-nyckelord. Varje nyckelord eller identifierare utlöser en token som skapas och överlämnas till parsern.

Parsern skapar ett frågeträd som avgränsar frågan till identifierbara delar för att förstå vilka tabeller som ingår, vilka filter som har tillämpats osv. Delarna i ett frågeträd är:

  • Kommandotyp – SELECT, INSERT, UPDATE eller DELETE.
  • Intervalltabellpost (RTE) – en lista över relationer, ie tabeller, underfrågor, resultat av kopplingar osv. I en SELECT-instruktion visas dessa objekt efter nyckelordet FROM.
  • Resultatrelation – resultatrelationen för kommandona INSERT, UPDATE och DELETE är tabellen eller vyn där ändringarna ska börja gälla.
  • Mållista – resultatet av frågan, identifierad mellan nyckelorden SELECT och FROM. DELETE-kommandon ger inget resultat, så planeraren lägger till en särskild post som gör att kören kan hitta raden som ska tas bort. INSERT-kommandon identifierar de nya raderna som ska gå in i resultatrelationen. För UPDATE-kommandon beskriver mållistan de nya raderna som ska ersätta de gamla.
  • Kvalificering – ett booleskt värde som anger om åtgärden för den slutliga resultatraden ska köras eller inte. Den motsvarar WHERE-satsen i en SQL-instruktion.
  • Kopplingsträd – det här trädet kan vara en lista över FROM-objekten. Kopplingar kan göras i valfri ordning eller i en viss ordning, till exempel yttre kopplingar.
  • Andra – objekt som inte är relevanta i det här skedet, till exempel ORDER BY-satsen.

Brännare

Utdata från parsern skickas till transformerings - eller omskrivningsprocessen , såvida inte ett fel hittas i vilket fall ett felmeddelande returneras.

Frågeförfattaren skriver om frågetexten genom att tillämpa regler på den. Omskrivningen tar hänsyn till regler och skickar sedan den ändrade frågan till frågehanteraren. Säkerhet på radnivå implementeras i det här skedet.

Till exempel tillämpas regler på SELECT alltid som det sista steget, inklusive för INSERT-, UPDATE- och DELETE-frågor. Regler innebär också att UPDATE-frågor inte skriver över befintliga rader, i stället infogas en ny rad och den gamla raden är dold. När transaktionen har checkas in kan vakuumprocessen ta bort den dolda raden.

Planner

Planerarens uppgift är att ta frågereglerna och förstå vilket av de olika sätt som frågan kan köras på är snabbast.

Planeraren skapar ett planträd med noder som representerar fysiska åtgärder på data.

PostgreSQL använder en kostnadsbaserad frågeoptimerare för att hitta den optimala planen för en fråga. Planeraren utvärderar olika körningsplaner och uppskattar hur mycket av de resurser som krävs, till exempel CPU-cykler, I/O-åtgärder osv. Den här uppskattningen konverteras sedan till enheter, så kallade plankostnader. Planen med den lägsta kostnaden har valts.

Men när antalet kopplingar ökar växer antalet möjliga planer exponentiellt. Det blir omöjligt att utvärdera alla möjliga planer även för relativt enkla frågor. Heuristik och algoritmer används för att begränsa antalet möjliga planer. Resultatet är att den valda planen kanske inte är den optimala planen. Det är dock nästan optimalt och valt inom rimlig tid.

Kostnaden är planerarens bästa uppskattning. Syftet med kostnadsuppskattning är att jämföra olika körningsplaner för samma fråga i samma villkor. Planeraren använder statistik som samlats in på tabeller och rader för att skapa kostnadsuppskattningar för frågor. För att kostnadsuppskattningarna ska vara korrekta måste statistiken vara uppdaterad.

Uppdaterad statistik

Planeringskomponenten i frågeoptimeraren använder statistik om tabeller och rader för att skapa korrekta kostnadsuppskattningar.

ANALYZE samlar in statistik om databastabeller och lagrar resultatet i pg_statistic-systemkatalogen . Du måste köra ANALYZE om:

  • Du har inaktiverat autovacuum (som normalt analyserar tabeller automatiskt)
  • Du har inaktiverat autovacuum och har inte kört ANALYZE nyligen
  • Någon av de föregående och det finns många INSERTS-, UPDATES- eller DELETE-instruktioner.

Kostnadsuppskattningar förlitar sig på uppdaterad statistik och om statistiken är inaktuell och en ineffektiv plan kan väljas. När ingen parameter skickas till ANALYZE granskas varje tabell i databasen.

Syntaxen för ANALYZE är:

ANALYZE [ VERBOSE ] [ ***table*** [ ( ***column*** [, ...] ) ] ]

VERBOSE visar förloppsmeddelanden för att visa vilken tabell som analyseras, tillsammans med viss statistik.

Schemalägg VACUUM och ANALYZE så att de körs dagligen under en låg användningstid. ANALYZE kan köras parallellt med andra aktiviteter eftersom det bara krävs ett läslås i måltabellen.

Utföraren

Den här fasen tar planen som skapats av planeraren och bearbetar den rekursivt för att extrahera den nödvändiga uppsättningen rader. Varje gång en plannod kallas kören måste leverera en rad, eller rapportera tillbaka för att säga att den har slutförts.

Kören utvärderar alla fyra SQL-frågetyperna:

  • SELECT
  • INSERT
  • UPDATE
  • DELETE

För SELECT returnerar kören varje rad tillbaka till klienten som resultatuppsättning.

För INSERT infogas varje returnerad rad i den angivna tabellen. Den här uppgiften utförs i en särskild nod på den översta nivån med namnet ModifyTable.

För UPDATE innehåller varje beräknad rad alla uppdaterade kolumnvärden plus rad-ID för målraden. Data skickas till en ModifyTable-nod, vilket skapar en uppdaterad rad och markerar den gamla raden som borttagen.

För DELETE är den enda kolumn som returneras av planen rad-ID:t. Noden ModifyTable använder rad-ID:t för att markera raden som borttagen.