upstream/postgresql
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2026-04-08 10:38:53 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions
postgresql/src/include/optimizer/prep.h

54 lines
1.4 KiB
C
Raw Normal View History

Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 02:22:35 -04:00
/*-------------------------------------------------------------------------
*
Change my-function-name-- to my_function_name, and optimizer renames.
1999-02-13 18:22:53 -05:00
* prep.h
Further improvements in cnfify: reduce amount of self-recursion in or_normalize, remove detection of duplicate subexpressions (since it's highly unlikely to be worth the amount of time it takes), and introduce a dnfify() entry point so that unintelligible backwards logic in UNION processing can be eliminated. This is just an intermediate step --- next thing is to look at not forcing the qual into CNF form when it would be better off in DNF form.
1999-09-12 14:08:17 -04:00
* prototypes for files in optimizer/prep/
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 02:22:35 -04:00
*
*
Update copyright for 2006. Update scripts.
2006-03-05 10:59:11 -05:00
* Portions Copyright (c) 1996-2006, PostgreSQL Global Development Group
Add: * Portions Copyright (c) 1996-2000, PostgreSQL, Inc to all files copyright Regents of Berkeley. Man, that's a lot of files.
2000-01-26 00:58:53 -05:00
* Portions Copyright (c) 1994, Regents of the University of California
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 02:22:35 -04:00
*
Get rid of adjust_appendrel_attr_needed(), which has been broken ever since we extended the appendrel mechanism to support UNION ALL optimization. The reason nobody noticed was that we are not actually using attr_needed data for appendrel children; hence it seems more reasonable to rip it out than fix it. Back-patch to 8.2 because an Assert failure is possible in corner cases. Per examination of an example from Jim Nasby. In HEAD, also get rid of AppendRelInfo.col_mappings, which is quite inadequate to represent UNION ALL situations; depend entirely on translated_vars instead.
2008-11-11 13:13:54 -05:00
* $PostgreSQL: pgsql/src/include/optimizer/prep.h,v 1.57.2.1 2008/11/11 18:13:54 tgl Exp $
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 02:22:35 -04:00
*
*-------------------------------------------------------------------------
*/
#ifndef PREP_H
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 01:04:48 -04:00
#define PREP_H
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 02:22:35 -04:00
More cleanup
1999-07-16 13:07:40 -04:00
#include "nodes/plannodes.h"
Replace planner's representation of relation sets, per pghackers discussion. Instead of Lists of integers, we now store variable-length bitmap sets. This should be faster as well as less error-prone.
2003-02-08 15:20:55 -05:00
#include "nodes/relation.h"
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 02:22:35 -04:00
IN clauses appearing at top level of WHERE can now be handled as joins. There are two implementation techniques: the executor understands a new JOIN_IN jointype, which emits at most one matching row per left-hand row, or the result of the IN's sub-select can be fed through a DISTINCT filter and then joined as an ordinary relation. Along the way, some minor code cleanup in the optimizer; notably, break out most of the jointree-rearrangement preprocessing in planner.c and put it in a new file prep/prepjointree.c.
2003-01-20 13:55:07 -05:00
/*
* prototypes for prepjointree.c
*/
Remove planner's private fields from Query struct, and put them into a new PlannerInfo struct, which is passed around instead of the bare Query in all the planning code. This commit is essentially just a code-beautification exercise, but it does open the door to making larger changes to the planner data structures without having to muck with the widely-known Query struct.
2005-06-05 18:32:58 -04:00
extern Node *pull_up_IN_clauses(PlannerInfo *root, Node *node);
extern Node *pull_up_subqueries(PlannerInfo *root, Node *jtnode,
Teach planner to convert simple UNION ALL subqueries into append relations, thereby sharing code with the inheritance case. This puts the UNION-ALL-view approach to partitioned tables on par with inheritance, so far as constraint exclusion is concerned: it works either way. (Still need to update the docs to say so.) The definition of "simple UNION ALL" is a little simpler than I would like --- basically the union arms can only be SELECT * FROM foo --- but it's good enough for partitioned-table cases.
2006-02-03 16:08:49 -05:00
bool below_outer_join, bool append_rel_member);
Remove planner's private fields from Query struct, and put them into a new PlannerInfo struct, which is passed around instead of the bare Query in all the planning code. This commit is essentially just a code-beautification exercise, but it does open the door to making larger changes to the planner data structures without having to muck with the widely-known Query struct.
2005-06-05 18:32:58 -04:00
extern void reduce_outer_joins(PlannerInfo *root);
Replace planner's representation of relation sets, per pghackers discussion. Instead of Lists of integers, we now store variable-length bitmap sets. This should be faster as well as less error-prone.
2003-02-08 15:20:55 -05:00
extern Relids get_relids_in_jointree(Node *jtnode);
Remove planner's private fields from Query struct, and put them into a new PlannerInfo struct, which is passed around instead of the bare Query in all the planning code. This commit is essentially just a code-beautification exercise, but it does open the door to making larger changes to the planner data structures without having to muck with the widely-known Query struct.
2005-06-05 18:32:58 -04:00
extern Relids get_relids_for_join(PlannerInfo *root, int joinrelid);
IN clauses appearing at top level of WHERE can now be handled as joins. There are two implementation techniques: the executor understands a new JOIN_IN jointype, which emits at most one matching row per left-hand row, or the result of the IN's sub-select can be fed through a DISTINCT filter and then joined as an ordinary relation. Along the way, some minor code cleanup in the optimizer; notably, break out most of the jointree-rearrangement preprocessing in planner.c and put it in a new file prep/prepjointree.c.
2003-01-20 13:55:07 -05:00
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 02:22:35 -04:00
/*
Fix problems with grouping/aggregation in queries that use inheritance ... basically it was completely busted :-(
1999-06-06 13:38:11 -04:00
* prototypes for prepqual.c
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 02:22:35 -04:00
*/
Clean up the usage of canonicalize_qual(): in particular, be consistent about whether it is applied before or after eval_const_expressions(). I believe there were some corner cases where the system would fail to recognize that a partial index is applicable because of the previous inconsistency. Store normal rather than 'implicit AND' representations of constraints and index predicates in the catalogs. initdb forced due to representation change of constraints/predicates.
2003-12-28 16:57:37 -05:00
extern Expr *canonicalize_qual(Expr *qual);
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 02:22:35 -04:00
/*
Fix problems with grouping/aggregation in queries that use inheritance ... basically it was completely busted :-(
1999-06-06 13:38:11 -04:00
* prototypes for preptlist.c
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 02:22:35 -04:00
*/
Remove planner's private fields from Query struct, and put them into a new PlannerInfo struct, which is passed around instead of the bare Query in all the planning code. This commit is essentially just a code-beautification exercise, but it does open the door to making larger changes to the planner data structures without having to muck with the widely-known Query struct.
2005-06-05 18:32:58 -04:00
extern List *preprocess_targetlist(PlannerInfo *root, List *tlist);
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 02:22:35 -04:00
Fix problems with grouping/aggregation in queries that use inheritance ... basically it was completely busted :-(
1999-06-06 13:38:11 -04:00
/*
* prototypes for prepunion.c
*/
If a LIMIT is applied to a UNION ALL query, plan each UNION arm as if the limit were directly applied to it. This does not actually add a LIMIT plan node to the generated subqueries --- that would be useless overhead --- but it does cause the planner to prefer fast- start plans when the limit is small. After an idea from Phil Endecott.
2005-06-09 22:21:05 -04:00
extern Plan *plan_set_operations(PlannerInfo *root, double tuple_fraction,
Standard pgindent run for 8.1.
2005-10-14 22:49:52 -04:00
List **sortClauses);
Restructure handling of inheritance queries so that they work with outer joins, and clean things up a good deal at the same time. Append plan node no longer hacks on rangetable at runtime --- instead, all child tables are given their own RT entries during planning. Concept of multiple target tables pushed up into execMain, replacing bug-prone implementation within nodeAppend. Planner now supports generating Append plans for inheritance sets either at the top of the plan (the old way) or at the bottom. Expanding at the bottom is appropriate for tables used as sources, since they may appear inside an outer join; but we must still expand at the top when the target of an UPDATE or DELETE is an inheritance set, because we actually need a different targetlist and junkfilter for each target table in that case. Fortunately a target table can't be inside an outer join... Bizarre mutual recursion between union_planner and prepunion.c is gone --- in fact, union_planner doesn't really have much to do with union queries anymore, so I renamed it grouping_planner.
2000-11-11 19:37:02 -05:00
fix_parsetree_attnums was not nearly smart enough about walking parse trees. Also rewrite find_all_inheritors() in a more intelligible style.
1999-12-13 22:35:28 -05:00
extern List *find_all_inheritors(Oid parentrel);
Modify optimizer data structures so that IndexOptInfo lists built for create_index_paths are not immediately discarded, but are available for subsequent planner work. This allows avoiding redundant syscache lookups in several places. Change interface to operator selectivity estimation procedures to allow faster and more flexible estimation. Initdb forced due to change of pg_proc entries for selectivity functions!
2001-05-20 16:28:20 -04:00
Restructure planner's handling of inheritance. Rather than processing inheritance trees on-the-fly, which pretty well constrained us to considering only one way of planning inheritance, expand inheritance sets during the planner prep phase, and build a side data structure that can be consulted later to find which RTEs are members of which inheritance sets. As proof of concept, use the data structure to plan joins against inheritance sets more efficiently: we can now use indexes on the set members in inner-indexscan joins. (The generated plans could be improved further, but it'll take some executor changes.) This data structure will also support handling UNION ALL subqueries in the same way as inheritance sets, but that aspect of it isn't finished yet.
2006-01-31 16:39:25 -05:00
extern void expand_inherited_tables(PlannerInfo *root);
Restructure handling of inheritance queries so that they work with outer joins, and clean things up a good deal at the same time. Append plan node no longer hacks on rangetable at runtime --- instead, all child tables are given their own RT entries during planning. Concept of multiple target tables pushed up into execMain, replacing bug-prone implementation within nodeAppend. Planner now supports generating Append plans for inheritance sets either at the top of the plan (the old way) or at the bottom. Expanding at the bottom is appropriate for tables used as sources, since they may appear inside an outer join; but we must still expand at the top when the target of an UPDATE or DELETE is an inheritance set, because we actually need a different targetlist and junkfilter for each target table in that case. Fortunately a target table can't be inside an outer join... Bizarre mutual recursion between union_planner and prepunion.c is gone --- in fact, union_planner doesn't really have much to do with union queries anymore, so I renamed it grouping_planner.
2000-11-11 19:37:02 -05:00
Restructure planner's handling of inheritance. Rather than processing inheritance trees on-the-fly, which pretty well constrained us to considering only one way of planning inheritance, expand inheritance sets during the planner prep phase, and build a side data structure that can be consulted later to find which RTEs are members of which inheritance sets. As proof of concept, use the data structure to plan joins against inheritance sets more efficiently: we can now use indexes on the set members in inner-indexscan joins. (The generated plans could be improved further, but it'll take some executor changes.) This data structure will also support handling UNION ALL subqueries in the same way as inheritance sets, but that aspect of it isn't finished yet.
2006-01-31 16:39:25 -05:00
extern Node *adjust_appendrel_attrs(Node *node, AppendRelInfo *appinfo);
New pgindent run with fixes suggested by Tom. Patch manually reviewed, initdb/regression tests pass.
2001-11-05 12:46:40 -05:00
#endif /* PREP_H */
Reference in a new issue Copy permalink