1996-10-27 10:55:05 +01:00
|
|
|
#-------------------------------------------------------------------------
|
|
|
|
#
|
|
|
|
# Makefile--
|
|
|
|
# Makefile for executor
|
|
|
|
#
|
|
|
|
# IDENTIFICATION
|
2010-09-20 22:08:53 +02:00
|
|
|
# src/backend/executor/Makefile
|
1996-10-27 10:55:05 +01:00
|
|
|
#
|
|
|
|
#-------------------------------------------------------------------------
|
|
|
|
|
2000-08-31 18:12:35 +02:00
|
|
|
subdir = src/backend/executor
|
|
|
|
top_builddir = ../../..
|
|
|
|
include $(top_builddir)/src/Makefile.global
|
1996-10-27 10:55:05 +01:00
|
|
|
|
2019-11-05 23:41:07 +01:00
|
|
|
OBJS = \
|
|
|
|
execAmi.o \
|
Add support for asynchronous execution.
This implements asynchronous execution, which runs multiple parts of a
non-parallel-aware Append concurrently rather than serially to improve
performance when possible. Currently, the only node type that can be
run concurrently is a ForeignScan that is an immediate child of such an
Append. In the case where such ForeignScans access data on different
remote servers, this would run those ForeignScans concurrently, and
overlap the remote operations to be performed simultaneously, so it'll
improve the performance especially when the operations involve
time-consuming ones such as remote join and remote aggregation.
We may extend this to other node types such as joins or aggregates over
ForeignScans in the future.
This also adds the support for postgres_fdw, which is enabled by the
table-level/server-level option "async_capable". The default is false.
Robert Haas, Kyotaro Horiguchi, Thomas Munro, and myself. This commit
is mostly based on the patch proposed by Robert Haas, but also uses
stuff from the patch proposed by Kyotaro Horiguchi and from the patch
proposed by Thomas Munro. Reviewed by Kyotaro Horiguchi, Konstantin
Knizhnik, Andrey Lepikhov, Movead Li, Thomas Munro, Justin Pryzby, and
others.
Discussion: https://postgr.es/m/CA%2BTgmoaXQEt4tZ03FtQhnzeDEMzBck%2BLrni0UWHVVgOTnA6C1w%40mail.gmail.com
Discussion: https://postgr.es/m/CA%2BhUKGLBRyu0rHrDCMC4%3DRn3252gogyp1SjOgG8SEKKZv%3DFwfQ%40mail.gmail.com
Discussion: https://postgr.es/m/20200228.170650.667613673625155850.horikyota.ntt%40gmail.com
2021-03-31 11:45:00 +02:00
|
|
|
execAsync.o \
|
2019-11-05 23:41:07 +01:00
|
|
|
execCurrent.o \
|
|
|
|
execExpr.o \
|
|
|
|
execExprInterp.o \
|
|
|
|
execGrouping.o \
|
|
|
|
execIndexing.o \
|
|
|
|
execJunk.o \
|
|
|
|
execMain.o \
|
|
|
|
execParallel.o \
|
|
|
|
execPartition.o \
|
|
|
|
execProcnode.o \
|
|
|
|
execReplication.o \
|
|
|
|
execSRF.o \
|
|
|
|
execScan.o \
|
|
|
|
execTuples.o \
|
|
|
|
execUtils.o \
|
|
|
|
functions.o \
|
|
|
|
instrument.o \
|
|
|
|
nodeAgg.o \
|
|
|
|
nodeAppend.o \
|
|
|
|
nodeBitmapAnd.o \
|
|
|
|
nodeBitmapHeapscan.o \
|
|
|
|
nodeBitmapIndexscan.o \
|
|
|
|
nodeBitmapOr.o \
|
|
|
|
nodeCtescan.o \
|
|
|
|
nodeCustom.o \
|
|
|
|
nodeForeignscan.o \
|
|
|
|
nodeFunctionscan.o \
|
|
|
|
nodeGather.o \
|
|
|
|
nodeGatherMerge.o \
|
|
|
|
nodeGroup.o \
|
|
|
|
nodeHash.o \
|
|
|
|
nodeHashjoin.o \
|
Implement Incremental Sort
Incremental Sort is an optimized variant of multikey sort for cases when
the input is already sorted by a prefix of the requested sort keys. For
example when the relation is already sorted by (key1, key2) and we need
to sort it by (key1, key2, key3) we can simply split the input rows into
groups having equal values in (key1, key2), and only sort/compare the
remaining column key3.
This has a number of benefits:
- Reduced memory consumption, because only a single group (determined by
values in the sorted prefix) needs to be kept in memory. This may also
eliminate the need to spill to disk.
- Lower startup cost, because Incremental Sort produce results after each
prefix group, which is beneficial for plans where startup cost matters
(like for example queries with LIMIT clause).
We consider both Sort and Incremental Sort, and decide based on costing.
The implemented algorithm operates in two different modes:
- Fetching a minimum number of tuples without check of equality on the
prefix keys, and sorting on all columns when safe.
- Fetching all tuples for a single prefix group and then sorting by
comparing only the remaining (non-prefix) keys.
We always start in the first mode, and employ a heuristic to switch into
the second mode if we believe it's beneficial - the goal is to minimize
the number of unnecessary comparions while keeping memory consumption
below work_mem.
This is a very old patch series. The idea was originally proposed by
Alexander Korotkov back in 2013, and then revived in 2017. In 2018 the
patch was taken over by James Coleman, who wrote and rewrote most of the
current code.
There were many reviewers/contributors since 2013 - I've done my best to
pick the most active ones, and listed them in this commit message.
Author: James Coleman, Alexander Korotkov
Reviewed-by: Tomas Vondra, Andreas Karlsson, Marti Raudsepp, Peter Geoghegan, Robert Haas, Thomas Munro, Antonin Houska, Andres Freund, Alexander Kuzmenkov
Discussion: https://postgr.es/m/CAPpHfdscOX5an71nHd8WSUH6GNOCf=V7wgDaTXdDd9=goN-gfA@mail.gmail.com
Discussion: https://postgr.es/m/CAPpHfds1waRZ=NOmueYq0sx1ZSCnt+5QJvizT8ndT2=etZEeAQ@mail.gmail.com
2020-04-06 21:33:28 +02:00
|
|
|
nodeIncrementalSort.o \
|
2019-11-05 23:41:07 +01:00
|
|
|
nodeIndexonlyscan.o \
|
|
|
|
nodeIndexscan.o \
|
|
|
|
nodeLimit.o \
|
|
|
|
nodeLockRows.o \
|
|
|
|
nodeMaterial.o \
|
2021-07-14 02:45:00 +02:00
|
|
|
nodeMemoize.o \
|
2019-11-05 23:41:07 +01:00
|
|
|
nodeMergeAppend.o \
|
|
|
|
nodeMergejoin.o \
|
|
|
|
nodeModifyTable.o \
|
|
|
|
nodeNamedtuplestorescan.o \
|
|
|
|
nodeNestloop.o \
|
|
|
|
nodeProjectSet.o \
|
|
|
|
nodeRecursiveunion.o \
|
|
|
|
nodeResult.o \
|
|
|
|
nodeSamplescan.o \
|
|
|
|
nodeSeqscan.o \
|
|
|
|
nodeSetOp.o \
|
|
|
|
nodeSort.o \
|
|
|
|
nodeSubplan.o \
|
|
|
|
nodeSubqueryscan.o \
|
|
|
|
nodeTableFuncscan.o \
|
2021-02-27 10:59:36 +01:00
|
|
|
nodeTidrangescan.o \
|
2019-11-05 23:41:07 +01:00
|
|
|
nodeTidscan.o \
|
|
|
|
nodeUnique.o \
|
|
|
|
nodeValuesscan.o \
|
|
|
|
nodeWindowAgg.o \
|
|
|
|
nodeWorktablescan.o \
|
|
|
|
spi.o \
|
|
|
|
tqueue.o \
|
|
|
|
tstoreReceiver.o
|
1996-10-27 10:55:05 +01:00
|
|
|
|
2008-02-19 11:30:09 +01:00
|
|
|
include $(top_srcdir)/src/backend/common.mk
|