|
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
|
*
|
|
|
|
|
* 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 void ExplainInitState(ExplainState *es);
|
|
|
|
|
|
|
|
|
|
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);
|
|
|
|
|
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 */
|
