ok
Direktori : /opt/alt/postgresql11/usr/share/doc/alt-postgresql11-9.2.24/html/ |
Current File : //opt/alt/postgresql11/usr/share/doc/alt-postgresql11-9.2.24/html/query-path.html |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <HTML ><HEAD ><TITLE >The Path of a Query</TITLE ><META NAME="GENERATOR" CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK REV="MADE" HREF="mailto:pgsql-docs@postgresql.org"><LINK REL="HOME" TITLE="PostgreSQL 9.2.24 Documentation" HREF="index.html"><LINK REL="UP" TITLE="Overview of PostgreSQL Internals" HREF="overview.html"><LINK REL="PREVIOUS" TITLE="Overview of PostgreSQL Internals" HREF="overview.html"><LINK REL="NEXT" TITLE="How Connections are Established" HREF="connect-estab.html"><LINK REL="STYLESHEET" TYPE="text/css" HREF="stylesheet.css"><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1"><META NAME="creation" CONTENT="2017-11-06T22:43:11"></HEAD ><BODY CLASS="SECT1" ><DIV CLASS="NAVHEADER" ><TABLE SUMMARY="Header navigation table" WIDTH="100%" BORDER="0" CELLPADDING="0" CELLSPACING="0" ><TR ><TH COLSPAN="5" ALIGN="center" VALIGN="bottom" ><A HREF="index.html" >PostgreSQL 9.2.24 Documentation</A ></TH ></TR ><TR ><TD WIDTH="10%" ALIGN="left" VALIGN="top" ><A TITLE="Overview of PostgreSQL Internals" HREF="overview.html" ACCESSKEY="P" >Prev</A ></TD ><TD WIDTH="10%" ALIGN="left" VALIGN="top" ><A HREF="overview.html" ACCESSKEY="U" >Up</A ></TD ><TD WIDTH="60%" ALIGN="center" VALIGN="bottom" >Chapter 44. Overview of PostgreSQL Internals</TD ><TD WIDTH="20%" ALIGN="right" VALIGN="top" ><A TITLE="How Connections are Established" HREF="connect-estab.html" ACCESSKEY="N" >Next</A ></TD ></TR ></TABLE ><HR ALIGN="LEFT" WIDTH="100%"></DIV ><DIV CLASS="SECT1" ><H1 CLASS="SECT1" ><A NAME="QUERY-PATH" >44.1. The Path of a Query</A ></H1 ><P > Here we give a short overview of the stages a query has to pass in order to obtain a result. </P ><DIV CLASS="PROCEDURE" ><OL TYPE="1" ><LI CLASS="STEP" ><P > A connection from an application program to the <SPAN CLASS="PRODUCTNAME" >PostgreSQL</SPAN > server has to be established. The application program transmits a query to the server and waits to receive the results sent back by the server. </P ></LI ><LI CLASS="STEP" ><P > The <I CLASS="FIRSTTERM" >parser stage</I > checks the query transmitted by the application program for correct syntax and creates a <I CLASS="FIRSTTERM" >query tree</I >. </P ></LI ><LI CLASS="STEP" ><P > The <I CLASS="FIRSTTERM" >rewrite system</I > takes the query tree created by the parser stage and looks for any <I CLASS="FIRSTTERM" >rules</I > (stored in the <I CLASS="FIRSTTERM" >system catalogs</I >) to apply to the query tree. It performs the transformations given in the <I CLASS="FIRSTTERM" >rule bodies</I >. </P ><P > One application of the rewrite system is in the realization of <I CLASS="FIRSTTERM" >views</I >. Whenever a query against a view (i.e., a <I CLASS="FIRSTTERM" >virtual table</I >) is made, the rewrite system rewrites the user's query to a query that accesses the <I CLASS="FIRSTTERM" >base tables</I > given in the <I CLASS="FIRSTTERM" >view definition</I > instead. </P ></LI ><LI CLASS="STEP" ><P > The <I CLASS="FIRSTTERM" >planner/optimizer</I > takes the (rewritten) query tree and creates a <I CLASS="FIRSTTERM" >query plan</I > that will be the input to the <I CLASS="FIRSTTERM" >executor</I >. </P ><P > It does so by first creating all possible <I CLASS="FIRSTTERM" >paths</I > leading to the same result. For example if there is an index on a relation to be scanned, there are two paths for the scan. One possibility is a simple sequential scan and the other possibility is to use the index. Next the cost for the execution of each path is estimated and the cheapest path is chosen. The cheapest path is expanded into a complete plan that the executor can use. </P ></LI ><LI CLASS="STEP" ><P > The executor recursively steps through the <I CLASS="FIRSTTERM" >plan tree</I > and retrieves rows in the way represented by the plan. The executor makes use of the <I CLASS="FIRSTTERM" >storage system</I > while scanning relations, performs <I CLASS="FIRSTTERM" >sorts</I > and <I CLASS="FIRSTTERM" >joins</I >, evaluates <I CLASS="FIRSTTERM" >qualifications</I > and finally hands back the rows derived. </P ></LI ></OL ></DIV ><P > In the following sections we will cover each of the above listed items in more detail to give a better understanding of <SPAN CLASS="PRODUCTNAME" >PostgreSQL</SPAN >'s internal control and data structures. </P ></DIV ><DIV CLASS="NAVFOOTER" ><HR ALIGN="LEFT" WIDTH="100%"><TABLE SUMMARY="Footer navigation table" WIDTH="100%" BORDER="0" CELLPADDING="0" CELLSPACING="0" ><TR ><TD WIDTH="33%" ALIGN="left" VALIGN="top" ><A HREF="overview.html" ACCESSKEY="P" >Prev</A ></TD ><TD WIDTH="34%" ALIGN="center" VALIGN="top" ><A HREF="index.html" ACCESSKEY="H" >Home</A ></TD ><TD WIDTH="33%" ALIGN="right" VALIGN="top" ><A HREF="connect-estab.html" ACCESSKEY="N" >Next</A ></TD ></TR ><TR ><TD WIDTH="33%" ALIGN="left" VALIGN="top" >Overview of PostgreSQL Internals</TD ><TD WIDTH="34%" ALIGN="center" VALIGN="top" ><A HREF="overview.html" ACCESSKEY="U" >Up</A ></TD ><TD WIDTH="33%" ALIGN="right" VALIGN="top" >How Connections are Established</TD ></TR ></TABLE ></DIV ></BODY ></HTML >