1996-07-09 08:22:35 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
|
*
|
1999-02-14 00:22:53 +01:00
|
|
|
* planner.h
|
1996-07-09 08:22:35 +02:00
|
|
|
* prototypes for planner.c.
|
|
|
|
|
*
|
2019-01-29 21:48:51 +01:00
|
|
|
* Note that the primary entry points for planner.c are declared in
|
|
|
|
|
* optimizer/optimizer.h, because they're intended to be called from
|
|
|
|
|
* non-planner code. Declarations here are meant for use by other
|
|
|
|
|
* planner modules.
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
2023-01-02 21:00:37 +01:00
|
|
|
* Portions Copyright (c) 1996-2023, PostgreSQL Global Development Group
|
2000-01-26 06:58:53 +01:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/include/optimizer/planner.h
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
|
*/
|
|
|
|
|
#ifndef PLANNER_H
|
|
|
|
|
#define PLANNER_H
|
|
|
|
|
|
2019-01-29 22:49:25 +01:00
|
|
|
#include "nodes/pathnodes.h"
|
1997-11-26 02:14:33 +01:00
|
|
|
#include "nodes/plannodes.h"
|
1997-11-25 23:07:18 +01:00
|
|
|
|
2000-08-21 22:55:31 +02:00
|
|
|
|
2007-05-25 19:54:25 +02:00
|
|
|
/* Hook for plugins to get control in planner() */
|
|
|
|
|
typedef PlannedStmt *(*planner_hook_type) (Query *parse,
|
2020-03-30 06:51:05 +02:00
|
|
|
const char *query_string,
|
2007-05-25 19:54:25 +02:00
|
|
|
int cursorOptions,
|
|
|
|
|
ParamListInfo boundParams);
|
2007-07-25 14:22:54 +02:00
|
|
|
extern PGDLLIMPORT planner_hook_type planner_hook;
|
2007-05-25 19:54:25 +02:00
|
|
|
|
2016-04-12 21:23:14 +02:00
|
|
|
/* Hook for plugins to get control when grouping_planner() plans upper rels */
|
2016-03-15 00:23:29 +01:00
|
|
|
typedef void (*create_upper_paths_hook_type) (PlannerInfo *root,
|
2016-04-12 21:23:14 +02:00
|
|
|
UpperRelationKind stage,
|
|
|
|
|
RelOptInfo *input_rel,
|
2018-04-02 16:51:50 +02:00
|
|
|
RelOptInfo *output_rel,
|
|
|
|
|
void *extra);
|
2016-03-15 00:23:29 +01:00
|
|
|
extern PGDLLIMPORT create_upper_paths_hook_type create_upper_paths_hook;
|
|
|
|
|
|
2007-05-25 19:54:25 +02:00
|
|
|
|
2020-03-30 06:51:05 +02:00
|
|
|
extern PlannedStmt *standard_planner(Query *parse, const char *query_string,
|
|
|
|
|
int cursorOptions,
|
2007-05-25 19:54:25 +02:00
|
|
|
ParamListInfo boundParams);
|
2009-01-09 16:46:11 +01:00
|
|
|
|
Make the upper part of the planner work by generating and comparing Paths.
I've been saying we needed to do this for more than five years, and here it
finally is. This patch removes the ever-growing tangle of spaghetti logic
that grouping_planner() used to use to try to identify the best plan for
post-scan/join query steps. Now, there is (nearly) independent
consideration of each execution step, and entirely separate construction of
Paths to represent each of the possible ways to do that step. We choose
the best Path or set of Paths using the same add_path() logic that's been
used inside query_planner() for years.
In addition, this patch removes the old restriction that subquery_planner()
could return only a single Plan. It now returns a RelOptInfo containing a
set of Paths, just as query_planner() does, and the parent query level can
use each of those Paths as the basis of a SubqueryScanPath at its level.
This allows finding some optimizations that we missed before, wherein a
subquery was capable of returning presorted data and thereby avoiding a
sort in the parent level, making the overall cost cheaper even though
delivering sorted output was not the cheapest plan for the subquery in
isolation. (A couple of regression test outputs change in consequence of
that. However, there is very little change in visible planner behavior
overall, because the point of this patch is not to get immediate planning
benefits but to create the infrastructure for future improvements.)
There is a great deal left to do here. This patch unblocks a lot of
planner work that was basically impractical in the old code structure,
such as allowing FDWs to implement remote aggregation, or rewriting
plan_set_operations() to allow consideration of multiple implementation
orders for set operations. (The latter will likely require a full
rewrite of plan_set_operations(); what I've done here is only to fix it
to return Paths not Plans.) I have also left unfinished some localized
refactoring in createplan.c and planner.c, because it was not necessary
to get this patch to a working state.
Thanks to Robert Haas, David Rowley, and Amit Kapila for review.
2016-03-07 21:58:22 +01:00
|
|
|
extern PlannerInfo *subquery_planner(PlannerGlobal *glob, Query *parse,
|
2008-10-04 23:56:55 +02:00
|
|
|
PlannerInfo *parent_root,
|
Make the upper part of the planner work by generating and comparing Paths.
I've been saying we needed to do this for more than five years, and here it
finally is. This patch removes the ever-growing tangle of spaghetti logic
that grouping_planner() used to use to try to identify the best plan for
post-scan/join query steps. Now, there is (nearly) independent
consideration of each execution step, and entirely separate construction of
Paths to represent each of the possible ways to do that step. We choose
the best Path or set of Paths using the same add_path() logic that's been
used inside query_planner() for years.
In addition, this patch removes the old restriction that subquery_planner()
could return only a single Plan. It now returns a RelOptInfo containing a
set of Paths, just as query_planner() does, and the parent query level can
use each of those Paths as the basis of a SubqueryScanPath at its level.
This allows finding some optimizations that we missed before, wherein a
subquery was capable of returning presorted data and thereby avoiding a
sort in the parent level, making the overall cost cheaper even though
delivering sorted output was not the cheapest plan for the subquery in
isolation. (A couple of regression test outputs change in consequence of
that. However, there is very little change in visible planner behavior
overall, because the point of this patch is not to get immediate planning
benefits but to create the infrastructure for future improvements.)
There is a great deal left to do here. This patch unblocks a lot of
planner work that was basically impractical in the old code structure,
such as allowing FDWs to implement remote aggregation, or rewriting
plan_set_operations() to allow consideration of multiple implementation
orders for set operations. (The latter will likely require a full
rewrite of plan_set_operations(); what I've done here is only to fix it
to return Paths not Plans.) I have also left unfinished some localized
refactoring in createplan.c and planner.c, because it was not necessary
to get this patch to a working state.
Thanks to Robert Haas, David Rowley, and Amit Kapila for review.
2016-03-07 21:58:22 +01:00
|
|
|
bool hasRecursion, double tuple_fraction);
|
2012-07-21 23:45:07 +02:00
|
|
|
|
Allow foreign tables to participate in inheritance.
Foreign tables can now be inheritance children, or parents. Much of the
system was already ready for this, but we had to fix a few things of
course, mostly in the area of planner and executor handling of row locks.
As side effects of this, allow foreign tables to have NOT VALID CHECK
constraints (and hence to accept ALTER ... VALIDATE CONSTRAINT), and to
accept ALTER SET STORAGE and ALTER SET WITH/WITHOUT OIDS. Continuing to
disallow these things would've required bizarre and inconsistent special
cases in inheritance behavior. Since foreign tables don't enforce CHECK
constraints anyway, a NOT VALID one is a complete no-op, but that doesn't
mean we shouldn't allow it. And it's possible that some FDWs might have
use for SET STORAGE or SET WITH OIDS, though doubtless they will be no-ops
for most.
An additional change in support of this is that when a ModifyTable node
has multiple target tables, they will all now be explicitly identified
in EXPLAIN output, for example:
Update on pt1 (cost=0.00..321.05 rows=3541 width=46)
Update on pt1
Foreign Update on ft1
Foreign Update on ft2
Update on child3
-> Seq Scan on pt1 (cost=0.00..0.00 rows=1 width=46)
-> Foreign Scan on ft1 (cost=100.00..148.03 rows=1170 width=46)
-> Foreign Scan on ft2 (cost=100.00..148.03 rows=1170 width=46)
-> Seq Scan on child3 (cost=0.00..25.00 rows=1200 width=46)
This was done mainly to provide an unambiguous place to attach "Remote SQL"
fields, but it is useful for inherited updates even when no foreign tables
are involved.
Shigeru Hanada and Etsuro Fujita, reviewed by Ashutosh Bapat and Kyotaro
Horiguchi, some additional hacking by me
2015-03-22 18:53:11 +01:00
|
|
|
extern RowMarkType select_rowmark_type(RangeTblEntry *rte,
|
|
|
|
|
LockClauseStrength strength);
|
|
|
|
|
|
2018-09-14 06:06:30 +02:00
|
|
|
extern bool limit_needed(Query *parse);
|
|
|
|
|
|
2016-06-26 20:33:38 +02:00
|
|
|
extern void mark_partial_aggref(Aggref *agg, AggSplit aggsplit);
|
2016-06-26 18:08:12 +02:00
|
|
|
|
Make the upper part of the planner work by generating and comparing Paths.
I've been saying we needed to do this for more than five years, and here it
finally is. This patch removes the ever-growing tangle of spaghetti logic
that grouping_planner() used to use to try to identify the best plan for
post-scan/join query steps. Now, there is (nearly) independent
consideration of each execution step, and entirely separate construction of
Paths to represent each of the possible ways to do that step. We choose
the best Path or set of Paths using the same add_path() logic that's been
used inside query_planner() for years.
In addition, this patch removes the old restriction that subquery_planner()
could return only a single Plan. It now returns a RelOptInfo containing a
set of Paths, just as query_planner() does, and the parent query level can
use each of those Paths as the basis of a SubqueryScanPath at its level.
This allows finding some optimizations that we missed before, wherein a
subquery was capable of returning presorted data and thereby avoiding a
sort in the parent level, making the overall cost cheaper even though
delivering sorted output was not the cheapest plan for the subquery in
isolation. (A couple of regression test outputs change in consequence of
that. However, there is very little change in visible planner behavior
overall, because the point of this patch is not to get immediate planning
benefits but to create the infrastructure for future improvements.)
There is a great deal left to do here. This patch unblocks a lot of
planner work that was basically impractical in the old code structure,
such as allowing FDWs to implement remote aggregation, or rewriting
plan_set_operations() to allow consideration of multiple implementation
orders for set operations. (The latter will likely require a full
rewrite of plan_set_operations(); what I've done here is only to fix it
to return Paths not Plans.) I have also left unfinished some localized
refactoring in createplan.c and planner.c, because it was not necessary
to get this patch to a working state.
Thanks to Robert Haas, David Rowley, and Amit Kapila for review.
2016-03-07 21:58:22 +01:00
|
|
|
extern Path *get_cheapest_fractional_path(RelOptInfo *rel,
|
|
|
|
|
double tuple_fraction);
|
|
|
|
|
|
2012-08-27 04:48:55 +02:00
|
|
|
extern Expr *preprocess_phv_expression(PlannerInfo *root, Expr *expr);
|
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
#endif /* PLANNER_H */
|
