Identificer komponenterne til behandling af forespørgsler

  • 7 minutter

Der er fire separate faser til udførelse af forespørgslen. I udførelsesrækkefølgen er disse faser:

  1. Parsing
  2. Transformation (omskrivning)
  3. Planlægning
  4. Henrettelse

Fortolkeren

Fortolkeren er ansvarlig for at kontrollere forespørgselsstrengen for gyldig syntaks. Fortolkeren har to hoveddele:

  • gram.y, der består af et sæt grammatiske regler og tilsvarende handlinger.
  • scan.1lexer, som genkender id'er og SQL-nøgleord. Hvert nøgleord eller identifikator udløser et token, der oprettes og overdrages til fortolkeren.

Fortolkeren opretter et forespørgselstræ, der adskiller forespørgslen i identificerbare dele for at forstå, hvilke tabeller der er involveret, hvilke filtre der blev anvendt osv. Delene i et forespørgselstræ er:

  • kommandotype – SELECT, INSERT, UPDATE eller DELETE.
  • OMRÅDEtabelpost (RTE) – en liste over relationer, ie tabeller, underforespørgsler, resultater af joinforbindelser osv. I en SELECT-sætning vises disse elementer efter nøgleordet FROM.
  • Resultatrelation – resultatrelationen for kommandoerne INSERT, UPDATE og DELETE er den tabel eller visning, hvor ændringerne skal træde i kraft.
  • målliste – resultaterne af forespørgslen, der er identificeret mellem nøgleordene SELECT og FROM. DELETE-kommandoer giver ikke et resultat, så planlæggeren tilføjer en særlig post for at gøre det muligt for eksekveren at finde den række, der skal slettes. INSERT-kommandoer identificerer de nye rækker, der skal gå til resultatrelationen. I forbindelse med UPDATE-kommandoer beskriver mållisten de nye rækker, der skal erstatte de gamle.
  • Qualification – en boolesk værdi, der angiver, om handlingen for den endelige resultatrække skal udføres. Det svarer til WHERE-delsætningen i en SQL-sætning.
  • jointræ – dette træ kan være en liste over FROM-elementerne. Joinforbindelser kan udføres i en hvilken som helst rækkefølge eller i en bestemt rækkefølge, f.eks. Ydre joinforbindelser.
  • Andre – elementer, der ikke er relevante i denne fase, f.eks. ORDER BY-delsætningen.

Brænder

Outputtet fra fortolkeren overføres til den transformations- eller omskrivningsproces proces, medmindre der findes en fejl, i hvilket tilfælde der returneres en fejlmeddelelse.

Forespørgselsforfatteren omskriver forespørgselsteksten ved at anvende regler på den. Omskrivningen tager regler i betragtning og overfører derefter den ændrede forespørgsel til forespørgselsplanlægningen. Sikkerhed på rækkeniveau implementeres i denne fase.

Regler for SELECT anvendes f.eks. altid som det sidste trin, herunder for forespørgsler af typen INSERT, UPDATE og DELETE. Regler betyder også, at OPDATERINGsforespørgsler ikke overskriver eksisterende rækker, i stedet indsættes der en ny række, og den gamle række er skjult. Når transaktionen er bekræftet, kan vakuumprocessen fjerne den skjulte række.

Planner

Opgaven for planlæggeren er at tage forespørgselsreglerne og forstå, hvilke af de forskellige måder forespørgslen kan udføres på, er den hurtigste.

Planlæggeren opretter et plantræ, hvor noder repræsenterer fysiske handlinger på dataene.

PostgreSQL bruger en omkostningsbaseret forespørgselsoptimering til at finde den optimale plan for en forespørgsel. Planlæggeren evaluerer forskellige udførelsesplaner og vurderer, hvor meget af de nødvendige ressourcer der er behov for, f.eks. CPU-cyklusser, I/O-handlinger osv. Dette estimat konverteres derefter til enheder, der kaldes planomkostninger. Planen med de laveste omkostninger vælges.

Men i takt med at antallet af joinforbindelser stiger, vokser antallet af mulige planer eksponentielt. Det bliver umuligt at evaluere alle mulige planer, selv for relativt enkle forespørgsler. Heuristik og algoritmer bruges til at begrænse antallet af mulige planer. Resultatet er, at den valgte plan muligvis ikke er den optimale plan. Det er dog næsten optimalt og valgt i et rimeligt tidsrum.

Omkostningerne er planlæggerens bedste estimat. Formålet med omkostningsestimering er at sammenligne forskellige udførelsesplaner for samme forespørgsel i samme betingelser. Planlæggeren bruger statistikker, der indsamles på tabeller og rækker, til at udarbejde omkostningsestimater for forespørgsler. Hvis omkostningsestimaterne skal være nøjagtige, skal statistikkerne være opdaterede.

Opdateret statistik

Planlægningskomponenten i forespørgselsoptimeringsprogrammet bruger statistikker om tabeller og rækker til at producere nøjagtige omkostningsestimater.

ANALYSér indsamler statistikker om databasetabeller og gemmer resultaterne i pg_statistic systemkatalog. Du skal køre ANALYSÉR, hvis:

  • Du har deaktiveret autovacuum (som normalt analyserer tabeller automatisk)
  • Du har deaktiveret autovacuumog har ikke kørt ANALYSér for nylig
  • En af de forrige, og der er mange INSERTS-, UPDATES- eller DELETE-sætninger.

Omkostningsestimater er afhængige af up-to-datostatistik, og hvis statistikkerne er forældede, og der kan vælges en ineffektiv plan. Når der ikke overføres en parameter til ANALYSér, undersøges alle tabeller i databasen.

Syntaksen for ANALYSér er:

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

VERBOSE viser statusmeddelelser for at vise, hvilken tabel der analyseres, sammen med nogle statistikker.

Planlæg, at VACUUM og ANALYSér skal køre dagligt i en tid med lavt forbrug. ANALYSér kan køre parallelt med andre aktiviteter, da det kun kræver en læselås i destinationstabellen.

Eksekutor

Denne fase tager den plan, der er oprettet af planlæggeren, og behandler den rekursivt for at udtrække det påkrævede sæt rækker. Hver gang en plannode kaldes eksekveren, skal den levere en række eller rapportere tilbage for at sige, at den er færdig.

Eksekveringsfilen evaluerer alle fire SQL-forespørgselstyper:

  • SELECT
  • INDSÆTTE
  • OPDATERING
  • SLETTE

I forbindelse med SELECTreturnerer eksekveren hver række tilbage til klienten som resultatsæt.

For INSERTindsættes hver returnerede række i den angivne tabel. Denne opgave udføres i en særlig plannode på øverste niveau, der kaldes ModifyTable.

For UPDATEindeholder hver beregnede række alle de opdaterede kolonneværdier plus række-id'et for destinationsrækken. Dataene sendes til noden ModifyTable, som opretter en opdateret række og markerer den gamle række som slettet.

For DELETEer den eneste kolonne, der returneres af planen, række-id'et. Noden ModifyTable bruger række-id'et til at markere rækken som slettet.