EDB Blog

Planning Queries Involving Foreign PostgreSQL Tables

ashutosh.bapat_enterprisedb.com's picture
Author: Ashutosh Bapat

Planning QueriesCost based optimization

A query may be executed in many different ways, modeled as plans in the query optimizer, differing in resources required and/or execution time. A typical DBMS's query optimizer tries to find all of the possible plans for executing a given query and chooses the fastest plan amongst those. But it's not possible to calculate the time required by a plan unless the query is executed. Thus an optimizer tries to associate an estimate of execution time with each possible plan and choose the one with the least estimated value. PostgreSQL is no different. It associates a cost with each possible plan. The cost is a rough estimation of the time required to execute the query. The plan with the lowest cost is chosen for execution. The time required to execute a query is a sum of time required to perform various operations involved in the plan being executed e.g. time required to scan the tables in the query, time required to compute joins, etc. Thus a plan's cost is a sum of the costs of operations involved in the plan. In order to efficiently and correctly estimate the cost of a plan, PostgreSQL maintains the statistics about sizes of tables, indexes, the values stores in various columns of tables and so on. In a DBMS, where data keeps changing, the statistics often gets stale and needs to be updated. PostgreSQL keeps the statistics up-to-date by frequently sampling the tables. This works reasonably well as long as the tables involved in the query are part of the DBMS.

But nowadays, often, applications run queries which require data external to the DBMS. PostgreSQL supports querying external data through a Foreign Data Wrapper (FDW), a method based on the SQL/MED standard. We will discuss the methods employed by the query optimizer to plan such queries and methods to maintain the statistics about the external data, especially the data residing in other PostgreSQL server/s, in this post.

Continue reading this post here at the community forum Postgres Rocks.  

Ashutosh Bapat is a Database Developer at EnterpriseDB