postgresql/src/backend/optimizer/plan
Andres Freund e6927270cd meson: Add initial version of meson based build system
Autoconf is showing its age, fewer and fewer contributors know how to wrangle
it. Recursive make has a lot of hard to resolve dependency issues and slow
incremental rebuilds. Our home-grown MSVC build system is hard to maintain for
developers not using Windows and runs tests serially. While these and other
issues could individually be addressed with incremental improvements, together
they seem best addressed by moving to a more modern build system.

After evaluating different build system choices, we chose to use meson, to a
good degree based on the adoption by other open source projects.

We decided that it's more realistic to commit a relatively early version of
the new build system and mature it in tree.

This commit adds an initial version of a meson based build system. It supports
building postgres on at least AIX, FreeBSD, Linux, macOS, NetBSD, OpenBSD,
Solaris and Windows (however only gcc is supported on aix, solaris). For
Windows/MSVC postgres can now be built with ninja (faster, particularly for
incremental builds) and msbuild (supporting the visual studio GUI, but
building slower).

Several aspects (e.g. Windows rc file generation, PGXS compatibility, LLVM
bitcode generation, documentation adjustments) are done in subsequent commits
requiring further review. Other aspects (e.g. not installing test-only
extensions) are not yet addressed.

When building on Windows with msbuild, builds are slower when using a visual
studio version older than 2019, because those versions do not support
MultiToolTask, required by meson for intra-target parallelism.

The plan is to remove the MSVC specific build system in src/tools/msvc soon
after reaching feature parity. However, we're not planning to remove the
autoconf/make build system in the near future. Likely we're going to keep at
least the parts required for PGXS to keep working around until all supported
versions build with meson.

Some initial help for postgres developers is at
https://wiki.postgresql.org/wiki/Meson

With contributions from Thomas Munro, John Naylor, Stone Tickle and others.

Author: Andres Freund <andres@anarazel.de>
Author: Nazir Bilal Yavuz <byavuz81@gmail.com>
Author: Peter Eisentraut <peter@eisentraut.org>
Reviewed-By: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Discussion: https://postgr.es/m/20211012083721.hvixq4pnh2pixr3j@alap3.anarazel.de
2022-09-21 22:37:17 -07:00
..
Makefile Split all OBJS style lines in makefiles into one-line-per-entry style. 2019-11-05 14:41:07 -08:00
README Remove useless whitespace at end of lines 2010-11-23 22:34:55 +02:00
analyzejoins.c Make PlaceHolderInfo lookup O(1). 2022-08-17 15:35:51 -04:00
createplan.c Harmonize more parameter names in bulk. 2022-09-20 13:09:30 -07:00
initsplan.c Use an explicit state flag to control PlaceHolderInfo creation. 2022-08-17 15:52:53 -04:00
meson.build meson: Add initial version of meson based build system 2022-09-21 22:37:17 -07:00
planagg.c Improve performance of ORDER BY / DISTINCT aggregates 2022-08-02 23:11:45 +12:00
planmain.c Make PlaceHolderInfo lookup O(1). 2022-08-17 15:35:51 -04:00
planner.c Harmonize more parameter names in bulk. 2022-09-20 13:09:30 -07:00
setrefs.c Estimate cost of elided SubqueryScan, Append, MergeAppend nodes better. 2022-07-19 11:18:19 -04:00
subselect.c More -Wshadow=compatible-local warning fixes 2022-08-26 02:35:40 +12:00

README

src/backend/optimizer/plan/README

Subselects
==========

Vadim B. Mikheev


From owner-pgsql-hackers@hub.org Fri Feb 13 09:01:19 1998
Received: from renoir.op.net (root@renoir.op.net [209.152.193.4])
	by candle.pha.pa.us (8.8.5/8.8.5) with ESMTP id JAA11576
	for <maillist@candle.pha.pa.us>; Fri, 13 Feb 1998 09:01:17 -0500 (EST)
Received: from hub.org (hub.org [209.47.148.200]) by renoir.op.net (o1/$Revision: 1.14 $) with ESMTP id IAA09761 for <maillist@candle.pha.pa.us>; Fri, 13 Feb 1998 08:41:22 -0500 (EST)
Received: from localhost (majordom@localhost) by hub.org (8.8.8/8.7.5) with SMTP id IAA08135; Fri, 13 Feb 1998 08:40:17 -0500 (EST)
Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Fri, 13 Feb 1998 08:38:42 -0500 (EST)
Received: (from majordom@localhost) by hub.org (8.8.8/8.7.5) id IAA06646 for pgsql-hackers-outgoing; Fri, 13 Feb 1998 08:38:35 -0500 (EST)
Received: from dune.krasnet.ru (dune.krasnet.ru [193.125.44.86]) by hub.org (8.8.8/8.7.5) with ESMTP id IAA04568 for <hackers@postgreSQL.org>; Fri, 13 Feb 1998 08:37:16 -0500 (EST)
Received: from sable.krasnoyarsk.su (dune.krasnet.ru [193.125.44.86])
	by dune.krasnet.ru (8.8.7/8.8.7) with ESMTP id UAA13717
	for <hackers@postgreSQL.org>; Fri, 13 Feb 1998 20:51:03 +0700 (KRS)
	(envelope-from vadim@sable.krasnoyarsk.su)
Message-ID: <34E44FBA.D64E7997@sable.krasnoyarsk.su>
Date: Fri, 13 Feb 1998 20:50:50 +0700
From: "Vadim B. Mikheev" <vadim@sable.krasnoyarsk.su>
Organization: ITTS (Krasnoyarsk)
X-Mailer: Mozilla 4.04 [en] (X11; I; FreeBSD 2.2.5-RELEASE i386)
MIME-Version: 1.0
To: PostgreSQL Developers List <hackers@postgreSQL.org>
Subject: [HACKERS] Subselects are in CVS...
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-pgsql-hackers@hub.org
Precedence: bulk
Status: OR

This is some implementation notes and opened issues...

First, implementation uses new type of parameters - PARAM_EXEC - to deal
with correlation Vars. When query_planner() is called, it first tries to
replace all upper queries Var referenced in current query with Param of
this type. Some global variables are used to keep mapping of Vars to
Params and Params to Vars.

After this, all current query' SubLinks are processed: for each SubLink
found in query' qual union_planner() (old planner() function) will be
called to plan corresponding subselect (union_planner() calls
query_planner() for "simple" query and supports UNIONs). After subselect
are planned, optimizer knows about is this correlated, un-correlated or
_undirect_ correlated (references some grand-parent Vars but no parent
ones: uncorrelated from the parent' point of view) query.

For uncorrelated and undirect correlated subqueries of EXPRession or
EXISTS type SubLinks will be replaced with "normal" clauses from
SubLink->Oper list (I changed this list to be list of EXPR nodes,
not just Oper ones). Right sides of these nodes are replaced with
PARAM_EXEC parameters. This is second use of new parameter type.
At run-time these parameters get value from result of subquery
evaluation (i.e. - from target list of subquery). Execution plan of
subquery itself becomes init plan of parent query. InitPlan knows
what parameters are to get values from subquery' results and will be
executed "on-demand" (for query select * from table where x > 0 and
y > (select max(a) from table_a) subquery will not be executed at all
if there are no tuples with x > 0 _and_ y is not used in index scan).

SubLinks for subqueries of all other types are transformed into
new type of Expr node - SUBPLAN_EXPR. Expr->args are just correlation
variables from _parent_ query. Expr->oper is new SubPlan node.

This node is used for InitPlan too. It keeps subquery range table,
indices of Params which are to get value from _parent_ query Vars
(i.e. - from Expr->args), indices of Params into which subquery'
results are to be substituted (this is for InitPlans), SubLink
and subquery' execution plan.

Plan node was changed to know about dependencies on Params from
parent queries and InitPlans, to keep list of changed Params
(from the above) and so be re-scanned if this list is not NULL.
Also, added list of InitPlans (actually, all of them for current
query are in topmost plan node now) and other SubPlans (from
plan->qual) - to initialize them and let them know about changed
Params (from the list of their "interests").

After all SubLinks are processed, query_planner() calls qual'
canonificator and does "normal" work. By using Params optimizer
is mostly unchanged.

Well, Executor. To get subplans re-evaluated without ExecutorStart()
and ExecutorEnd() (without opening and closing relations and indices
and without many palloc() and pfree() - this is what SQL-funcs does
on each call) ExecReScan() now supports most of Plan types...

Explanation of EXPLAIN.

vac=> explain select * from tmp where x >= (select max(x2) from test2
where y2 = y and exists (select * from tempx where tx = x));
NOTICE:  QUERY PLAN:

Seq Scan on tmp  (cost=40.03 size=101 width=8)
  SubPlan
  ^^^^^^^ subquery is in Seq Scan' qual, its plan is below
    ->  Aggregate  (cost=2.05 size=0 width=0)
          InitPlan
          ^^^^^^^^ EXISTS subsubquery is InitPlan of subquery
            ->  Seq Scan on tempx  (cost=4.33 size=1 width=4)
          ->  Result  (cost=2.05 size=0 width=0)
              ^^^^^^ EXISTS subsubquery was transformed into Param
                     and so we have Result node here
                ->  Index Scan on test2  (cost=2.05 size=1 width=4)


Opened issues.

1. No read permissions checking (easy, just not done yet).
2. readfuncs.c can't read subplan-s (easy, not critical, because of
   we currently nowhere use ascii representation of execution plans).
3. ExecReScan() doesn't support all plan types. At least support for
   MergeJoin has to be implemented.
4. Memory leaks in ExecReScan().
5. I need in advice: if subquery introduced with NOT IN doesn't return
   any tuples then qualification is failed, yes ?
6. Regression tests !!!!!!!!!!!!!!!!!!!!
   (Could we use data/queries from MySQL' crash.me ?
    Copyright-ed ? Could they give us rights ?)
7. Performance.
   - Should be good when subquery is transformed into InitPlan.
   - Something should be done for uncorrelated subqueries introduced
     with ANY/ALL - keep thinking. Currently, subplan will be re-scanned
     for each parent tuple - very slow...

Results of some test. TMP is table with x,y (int4-s), x in 0-9,
y = 100 - x, 1000 tuples (10 duplicates of each tuple). TEST2 is table
with x2, y2 (int4-s), x2 in 1-99, y2 = 100 -x2, 10000 tuples (100 dups).

   Trying

select * from tmp where x >= (select max(x2) from test2 where y2 = y);

   and

begin;
select y as ty, max(x2) as mx into table tsub from test2, tmp
where y2 = y group by ty;
vacuum tsub;
select x, y from tmp, tsub where x >= mx and y = ty;
drop table tsub;
end;

   Without index on test2(y2):

SubSelect         -> 320 sec
Using temp table  -> 32 sec

   Having index

SubSelect         -> 17 sec (2M of memory)
Using temp table  -> 32 sec (12M of memory: -S 8192)

Vadim