codekingpro/portable-devtools

1<?xml version="1.0" encoding="UTF-8" standalone="no"?>2<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>52.1. The Path of a Query</title><link rel="stylesheet" type="text/css" href="stylesheet.css" /><link rev="made" href="pgsql-docs@lists.postgresql.org" /><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot" /><link rel="prev" href="overview.html" title="Chapter 52. Overview of PostgreSQL Internals" /><link rel="next" href="connect-estab.html" title="52.2. How Connections Are Established" /></head><body id="docContent" class="container-fluid col-10"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="5" align="center">52.1. The Path of a Query</th></tr><tr><td width="10%" align="left"><a accesskey="p" href="overview.html" title="Chapter 52. Overview of PostgreSQL Internals">Prev</a> </td><td width="10%" align="left"><a accesskey="u" href="overview.html" title="Chapter 52. Overview of PostgreSQL Internals">Up</a></td><th width="60%" align="center">Chapter 52. Overview of PostgreSQL Internals</th><td width="10%" align="right"><a accesskey="h" href="index.html" title="PostgreSQL 16.3 Documentation">Home</a></td><td width="10%" align="right"> <a accesskey="n" href="connect-estab.html" title="52.2. How Connections Are Established">Next</a></td></tr></table><hr /></div><div class="sect1" id="QUERY-PATH"><div class="titlepage"><div><div><h2 class="title" style="clear: both">52.1. The Path of a Query <a href="#QUERY-PATH" class="id_link">#</a></h2></div></div></div><p>3    Here we give a short overview of the stages a query has to pass4    to obtain a result.5   </p><div class="procedure"><ol class="procedure" type="1"><li class="step"><p>6      A connection from an application program to the <span class="productname">PostgreSQL</span>7      server has to be established. The application program transmits a8      query to the server and waits to receive the results sent back by the9      server.10     </p></li><li class="step"><p>11      The <em class="firstterm">parser stage</em> checks the query12      transmitted by the application13      program for correct syntax and creates14      a <em class="firstterm">query tree</em>.15     </p></li><li class="step"><p>16      The <em class="firstterm">rewrite system</em> takes17      the query tree created by the parser stage and looks for18      any <em class="firstterm">rules</em> (stored in the19      <em class="firstterm">system catalogs</em>) to apply to20      the query tree.  It performs the21      transformations given in the <em class="firstterm">rule bodies</em>.22     </p><p>23      One application of the rewrite system is in the realization of24      <em class="firstterm">views</em>.25      Whenever a query against a view26      (i.e., a <em class="firstterm">virtual table</em>) is made,27      the rewrite system rewrites the user's query to28      a query that accesses the <em class="firstterm">base tables</em> given in29      the <em class="firstterm">view definition</em> instead.30     </p></li><li class="step"><p>31      The <em class="firstterm">planner/optimizer</em> takes32      the (rewritten) query tree and creates a33      <em class="firstterm">query plan</em> that will be the input to the34      <em class="firstterm">executor</em>.35     </p><p>36      It does so by first creating all possible <em class="firstterm">paths</em>37      leading to the same result. For example if there is an index on a38      relation to be scanned, there are two paths for the39      scan. One possibility is a simple sequential scan and the other40      possibility is to use the index. Next the cost for the execution of41      each path is estimated and the cheapest path is chosen.  The cheapest42      path is expanded into a complete plan that the executor can use.43     </p></li><li class="step"><p>44      The executor recursively steps through45      the <em class="firstterm">plan tree</em> and46      retrieves rows in the way represented by the plan.47      The executor makes use of the48      <em class="firstterm">storage system</em> while scanning49      relations, performs <em class="firstterm">sorts</em> and <em class="firstterm">joins</em>,50      evaluates <em class="firstterm">qualifications</em> and finally hands back the rows derived.51     </p></li></ol></div><p>52    In the following sections we will cover each of the above listed items53    in more detail to give a better understanding of <span class="productname">PostgreSQL</span>'s internal54    control and data structures.55   </p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="overview.html" title="Chapter 52. Overview of PostgreSQL Internals">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="overview.html" title="Chapter 52. Overview of PostgreSQL Internals">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="connect-estab.html" title="52.2. How Connections Are Established">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 52. Overview of PostgreSQL Internals </td><td width="20%" align="center"><a accesskey="h" href="index.html" title="PostgreSQL 16.3 Documentation">Home</a></td><td width="40%" align="right" valign="top"> 52.2. How Connections Are Established</td></tr></table></div></body></html>