|
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
|
*
|
|
|
|
|
* explain.h
|
|
|
|
|
* prototypes for explain.c
|
|
|
|
|
*
|
|
|
|
|
* Portions Copyright (c) 1996-2015, PostgreSQL Global Development Group
|
|
|
|
|
* Portions Copyright (c) 1994-5, Regents of the University of California
|
|
|
|
|
*
|
|
|
|
|
* src/include/commands/explain.h
|
|
|
|
|
*
|
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
|
*/
|
|
|
|
|
#ifndef EXPLAIN_H
|
|
|
|
|
#define EXPLAIN_H
|
|
|
|
|
|
|
|
|
|
#include "executor/executor.h"
|
|
|
|
|
#include "lib/stringinfo.h"
|
|
|
|
|
|
|
|
|
|
typedef enum ExplainFormat
|
|
|
|
|
{
|
|
|
|
|
EXPLAIN_FORMAT_TEXT,
|
|
|
|
|
EXPLAIN_FORMAT_XML,
|
|
|
|
|
EXPLAIN_FORMAT_JSON,
|
|
|
|
|
EXPLAIN_FORMAT_YAML
|
|
|
|
|
} ExplainFormat;
|
|
|
|
|
|
|
|
|
|
typedef struct ExplainState
|
|
|
|
|
{
|
|
|
|
|
StringInfo str; /* output buffer */
|
|
|
|
|
/* options */
|
|
|
|
|
bool verbose; /* be verbose */
|
|
|
|
|
bool analyze; /* print actual times */
|
|
|
|
|
bool costs; /* print estimated costs */
|
|
|
|
|
bool buffers; /* print buffer usage */
|
|
|
|
|
bool timing; /* print detailed node timing */
|
|
|
|
|
bool summary; /* print total planning and execution timing */
|
|
|
|
|
ExplainFormat format; /* output format */
|
|
|
|
|
/* other states */
|
|
|
|
|
PlannedStmt *pstmt; /* top of plan */
|
|
|
|
|
List *rtable; /* range table */
|
Improve ruleutils.c's heuristics for dealing with rangetable aliases.
The previous scheme had bugs in some corner cases involving tables that had
been renamed since a view was made. This could result in dumped views that
failed to reload or reloaded incorrectly, as seen in bug #7553 from Lloyd
Albin, as well as in some pgsql-hackers discussion back in January. Also,
its behavior for printing EXPLAIN plans was sometimes confusing because of
willingness to use the same alias for multiple RTEs (it was Ashutosh
Bapat's complaint about that aspect that started the January thread).
To fix, ensure that each RTE in the query has a unique unqualified alias,
by modifying the alias if necessary (we add "_" and digits as needed to
create a non-conflicting name). Then we can just print its variables with
that alias, avoiding the confusing and bug-prone scheme of sometimes
schema-qualifying variable names. In EXPLAIN, it proves to be expedient to
take the further step of only assigning such aliases to RTEs that are
actually referenced in the query, since the planner has a habit of
generating extra RTEs with the same alias in situations such as
inheritance-tree expansion.
Although this fixes a bug of very long standing, I'm hesitant to back-patch
such a noticeable behavioral change. My experiments while creating a
regression test convinced me that actually incorrect output (as opposed to
confusing output) occurs only in very narrow cases, which is backed up by
the lack of previous complaints from the field. So we may be better off
living with it in released branches; and in any case it'd be smart to let
this ripen awhile in HEAD before we consider back-patching it.
13 years ago
|
|
|
List *rtable_names; /* alias names for RTEs */
|
|
|
|
|
int indent; /* current indentation level */
|
|
|
|
|
List *grouping_stack; /* format-specific grouping state */
|
Improve performance of EXPLAIN with large range tables.
As of 9.3, ruleutils.c goes to some lengths to ensure that table and column
aliases used in its output are unique. Of course this takes more time than
was required before, which in itself isn't fatal. However, EXPLAIN was set
up so that recalculation of the unique aliases was repeated for each
subexpression printed in a plan. That results in O(N^2) time and memory
consumption for large plan trees, which did not happen in older branches.
Fortunately, the expensive work is the same across a whole plan tree,
so there is no need to repeat it; we can do most of the initialization
just once per query and re-use it for each subexpression. This buys
back most (not all) of the performance loss since 9.2.
We need an extra ExplainState field to hold the precalculated deparse
context. That's no problem in HEAD, but in the back branches, expanding
sizeof(ExplainState) seems risky because third-party extensions might
have local variables of that struct type. So, in 9.4 and 9.3, introduce
an auxiliary struct to keep sizeof(ExplainState) the same. We should
refactor the APIs to avoid such local variables in future, but that's
material for a separate HEAD-only commit.
Per gripe from Alexey Bashtanov. Back-patch to 9.3 where the issue
was introduced.
11 years ago
|
|
|
List *deparse_cxt; /* context list for deparsing expressions */
|
|
|
|
|
} ExplainState;
|
|
|
|
|
|
|
|
|
|
/* Hook for plugins to get control in ExplainOneQuery() */
|
|
|
|
|
typedef void (*ExplainOneQuery_hook_type) (Query *query,
|
|
|
|
|
IntoClause *into,
|
|
|
|
|
ExplainState *es,
|
|
|
|
|
const char *queryString,
|
|
|
|
|
ParamListInfo params);
|
|
|
|
|
extern PGDLLIMPORT ExplainOneQuery_hook_type ExplainOneQuery_hook;
|
|
|
|
|
|
|
|
|
|
/* Hook for plugins to get control in explain_get_index_name() */
|
|
|
|
|
typedef const char *(*explain_get_index_name_hook_type) (Oid indexId);
|
|
|
|
|
extern PGDLLIMPORT explain_get_index_name_hook_type explain_get_index_name_hook;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
extern void ExplainQuery(ExplainStmt *stmt, const char *queryString,
|
|
|
|
|
ParamListInfo params, DestReceiver *dest);
|
|
|
|
|
|
|
|
|
|
extern ExplainState *NewExplainState(void);
|
|
|
|
|
|
|
|
|
|
extern TupleDesc ExplainResultDesc(ExplainStmt *stmt);
|
|
|
|
|
|
Restructure SELECT INTO's parsetree representation into CreateTableAsStmt.
Making this operation look like a utility statement seems generally a good
idea, and particularly so in light of the desire to provide command
triggers for utility statements. The original choice of representing it as
SELECT with an IntoClause appendage had metastasized into rather a lot of
places, unfortunately, so that this patch is a great deal more complicated
than one might at first expect.
In particular, keeping EXPLAIN working for SELECT INTO and CREATE TABLE AS
subcommands required restructuring some EXPLAIN-related APIs. Add-on code
that calls ExplainOnePlan or ExplainOneUtility, or uses
ExplainOneQuery_hook, will need adjustment.
Also, the cases PREPARE ... SELECT INTO and CREATE RULE ... SELECT INTO,
which formerly were accepted though undocumented, are no longer accepted.
The PREPARE case can be replaced with use of CREATE TABLE AS EXECUTE.
The CREATE RULE case doesn't seem to have much real-world use (since the
rule would work only once before failing with "table already exists"),
so we'll not bother with that one.
Both SELECT INTO and CREATE TABLE AS still return a command tag of
"SELECT nnnn". There was some discussion of returning "CREATE TABLE nnnn",
but for the moment backwards compatibility wins the day.
Andres Freund and Tom Lane
14 years ago
|
|
|
extern void ExplainOneUtility(Node *utilityStmt, IntoClause *into,
|
|
|
|
|
ExplainState *es,
|
|
|
|
|
const char *queryString, ParamListInfo params);
|
|
|
|
|
|
Restructure SELECT INTO's parsetree representation into CreateTableAsStmt.
Making this operation look like a utility statement seems generally a good
idea, and particularly so in light of the desire to provide command
triggers for utility statements. The original choice of representing it as
SELECT with an IntoClause appendage had metastasized into rather a lot of
places, unfortunately, so that this patch is a great deal more complicated
than one might at first expect.
In particular, keeping EXPLAIN working for SELECT INTO and CREATE TABLE AS
subcommands required restructuring some EXPLAIN-related APIs. Add-on code
that calls ExplainOnePlan or ExplainOneUtility, or uses
ExplainOneQuery_hook, will need adjustment.
Also, the cases PREPARE ... SELECT INTO and CREATE RULE ... SELECT INTO,
which formerly were accepted though undocumented, are no longer accepted.
The PREPARE case can be replaced with use of CREATE TABLE AS EXECUTE.
The CREATE RULE case doesn't seem to have much real-world use (since the
rule would work only once before failing with "table already exists"),
so we'll not bother with that one.
Both SELECT INTO and CREATE TABLE AS still return a command tag of
"SELECT nnnn". There was some discussion of returning "CREATE TABLE nnnn",
but for the moment backwards compatibility wins the day.
Andres Freund and Tom Lane
14 years ago
|
|
|
extern void ExplainOnePlan(PlannedStmt *plannedstmt, IntoClause *into,
|
|
|
|
|
ExplainState *es, const char *queryString,
|
|
|
|
|
ParamListInfo params, const instr_time *planduration);
|
|
|
|
|
|
|
|
|
|
extern void ExplainPrintPlan(ExplainState *es, QueryDesc *queryDesc);
|
|
|
|
|
extern void ExplainPrintTriggers(ExplainState *es, QueryDesc *queryDesc);
|
|
|
|
|
|
|
|
|
|
extern void ExplainQueryText(ExplainState *es, QueryDesc *queryDesc);
|
|
|
|
|
|
|
|
|
|
extern void ExplainBeginOutput(ExplainState *es);
|
|
|
|
|
extern void ExplainEndOutput(ExplainState *es);
|
|
|
|
|
extern void ExplainSeparatePlans(ExplainState *es);
|
|
|
|
|
|
|
|
|
|
extern void ExplainPropertyList(const char *qlabel, List *data,
|
|
|
|
|
ExplainState *es);
|
Support GROUPING SETS, CUBE and ROLLUP.
This SQL standard functionality allows to aggregate data by different
GROUP BY clauses at once. Each grouping set returns rows with columns
grouped by in other sets set to NULL.
This could previously be achieved by doing each grouping as a separate
query, conjoined by UNION ALLs. Besides being considerably more concise,
grouping sets will in many cases be faster, requiring only one scan over
the underlying data.
The current implementation of grouping sets only supports using sorting
for input. Individual sets that share a sort order are computed in one
pass. If there are sets that don't share a sort order, additional sort &
aggregation steps are performed. These additional passes are sourced by
the previous sort step; thus avoiding repeated scans of the source data.
The code is structured in a way that adding support for purely using
hash aggregation or a mix of hashing and sorting is possible. Sorting
was chosen to be supported first, as it is the most generic method of
implementation.
Instead of, as in an earlier versions of the patch, representing the
chain of sort and aggregation steps as full blown planner and executor
nodes, all but the first sort are performed inside the aggregation node
itself. This avoids the need to do some unusual gymnastics to handle
having to return aggregated and non-aggregated tuples from underlying
nodes, as well as having to shut down underlying nodes early to limit
memory usage. The optimizer still builds Sort/Agg node to describe each
phase, but they're not part of the plan tree, but instead additional
data for the aggregation node. They're a convenient and preexisting way
to describe aggregation and sorting. The first (and possibly only) sort
step is still performed as a separate execution step. That retains
similarity with existing group by plans, makes rescans fairly simple,
avoids very deep plans (leading to slow explains) and easily allows to
avoid the sorting step if the underlying data is sorted by other means.
A somewhat ugly side of this patch is having to deal with a grammar
ambiguity between the new CUBE keyword and the cube extension/functions
named cube (and rollup). To avoid breaking existing deployments of the
cube extension it has not been renamed, neither has cube been made a
reserved keyword. Instead precedence hacking is used to make GROUP BY
cube(..) refer to the CUBE grouping sets feature, and not the function
cube(). To actually group by a function cube(), unlikely as that might
be, the function name has to be quoted.
Needs a catversion bump because stored rules may change.
Author: Andrew Gierth and Atri Sharma, with contributions from Andres Freund
Reviewed-By: Andres Freund, Noah Misch, Tom Lane, Svenne Krap, Tomas
Vondra, Erik Rijkers, Marti Raudsepp, Pavel Stehule
Discussion: CAOeZVidmVRe2jU6aMk_5qkxnB7dfmPROzM7Ur8JPW5j8Y5X-Lw@mail.gmail.com
10 years ago
|
|
|
extern void ExplainPropertyListNested(const char *qlabel, List *data,
|
|
|
|
|
ExplainState *es);
|
|
|
|
|
extern void ExplainPropertyText(const char *qlabel, const char *value,
|
|
|
|
|
ExplainState *es);
|
|
|
|
|
extern void ExplainPropertyInteger(const char *qlabel, int value,
|
|
|
|
|
ExplainState *es);
|
|
|
|
|
extern void ExplainPropertyLong(const char *qlabel, long value,
|
|
|
|
|
ExplainState *es);
|
|
|
|
|
extern void ExplainPropertyFloat(const char *qlabel, double value, int ndigits,
|
|
|
|
|
ExplainState *es);
|
|
|
|
|
|
|
|
|
|
#endif /* EXPLAIN_H */
|
