bd3daddaf2
subqueries into the same thing you'd have gotten from IN (except always with unknownEqFalse = true, so as to get the proper semantics for an EXISTS). I believe this fixes the last case within CVS HEAD in which an EXISTS could give worse performance than an equivalent IN subquery. The tricky part of this is that if the upper query probes the EXISTS for only a few rows, the hashing implementation can actually be worse than the default, and therefore we need to make a cost-based decision about which way to use. But at the time when the planner generates plans for subqueries, it doesn't really know how many times the subquery will be executed. The least invasive solution seems to be to generate both plans and postpone the choice until execution. Therefore, in a query that has been optimized this way, EXPLAIN will show two subplans for the EXISTS, of which only one will actually get executed. There is a lot more that could be done based on this infrastructure: in particular it's interesting to consider switching to the hash plan if we start out using the non-hashed plan but find a lot more upper rows going by than we expected. I have therefore left some minor inefficiencies in place, such as initializing both subplans even though we will currently only use one. |
||
|---|---|---|
| .. | ||
| .cvsignore | ||
| Makefile | ||
| README | ||
| analyze.c | ||
| gram.y | ||
| keywords.c | ||
| parse_agg.c | ||
| parse_clause.c | ||
| parse_coerce.c | ||
| parse_expr.c | ||
| parse_func.c | ||
| parse_node.c | ||
| parse_oper.c | ||
| parse_relation.c | ||
| parse_target.c | ||
| parse_type.c | ||
| parse_utilcmd.c | ||
| parser.c | ||
| scan.l | ||
| scansup.c | ||
README
$PostgreSQL: pgsql/src/backend/parser/README,v 1.10 2008/04/09 01:00:46 momjian Exp $ Parser ====== This directory does more than tokenize and parse SQL queries. It also creates Query structures for the various complex queries that are passed to the optimizer and then executor. parser.c things start here scan.l break query into tokens scansup.c handle escapes in input strings keywords.c turn keywords into specific tokens gram.y parse the tokens and fill query-type-specific structures analyze.c top level of parse analysis for optimizable queries parse_clause.c handle clauses like WHERE, ORDER BY, GROUP BY, ... parse_coerce.c handle coercing expressions to different data types parse_expr.c handle expressions like col, col + 3, x = 3 or x = 4 parse_oper.c handle operators in expressions parse_agg.c handle aggregates, like SUM(col1), AVG(col2), ... parse_func.c handle functions, table.column and column identifiers parse_node.c create nodes for various structures parse_target.c handle the result list of the query parse_relation.c support routines for tables and column handling parse_type.c support routines for data type handling parse_utilcmd.c parse analysis for utility commands (done at execution time)