diff options
author | Michael Paquier <michael@paquier.xyz> | 2023-05-17 10:19:17 +0900 |
---|---|---|
committer | Michael Paquier <michael@paquier.xyz> | 2023-05-17 10:19:17 +0900 |
commit | d8c3106bb60e4f87be595f241e173ba3c2b7aa2c (patch) | |
tree | 48ebeb093661e58b99c7d5645b40e4a5336524ab /src/include/nodes/primnodes.h | |
parent | 1d369c9e90f311ec98b07a259cac48c404c773d5 (diff) |
Add back SQLValueFunction for SQL keywords
This is equivalent to a revert of f193883 and fb32748, with the addition
that the declaration of the SQLValueFunction node needs to gain a couple
of node_attr for query jumbling. The performance impact of removing the
function call inlining is proving to be too huge for some workloads
where these are used. A worst-case test case of involving only simple
SELECT queries with a SQL keyword is proving to lead to a reduction of
10% in TPS via pgbench and prepared queries on a high-end machine.
None of the tests I ran back for this set of changes saw such a huge
gap, but Alexander Lakhin and Andres Freund have found that this can be
noticeable. Keeping the older performance would mean to do more
inlining in the executor when using COERCE_SQL_SYNTAX for a function
expression, similarly to what SQLValueFunction does. This requires more
redesign work and there is little time until 16beta1 is released, so for
now reverting the change is the best way forward, bringing back the
previous performance.
Bump catalog version.
Reported-by: Alexander Lakhin
Discussion: https://postgr.es/m/b32bed1b-0746-9b20-1472-4bdc9ca66d52@gmail.com
Diffstat (limited to 'src/include/nodes/primnodes.h')
-rw-r--r-- | src/include/nodes/primnodes.h | 43 |
1 files changed, 43 insertions, 0 deletions
diff --git a/src/include/nodes/primnodes.h b/src/include/nodes/primnodes.h index be9c29f0bfb..08e7dae73f1 100644 --- a/src/include/nodes/primnodes.h +++ b/src/include/nodes/primnodes.h @@ -1446,6 +1446,49 @@ typedef struct MinMaxExpr } MinMaxExpr; /* + * SQLValueFunction - parameterless functions with special grammar productions + * + * The SQL standard categorizes some of these as <datetime value function> + * and others as <general value specification>. We call 'em SQLValueFunctions + * for lack of a better term. We store type and typmod of the result so that + * some code doesn't need to know each function individually, and because + * we would need to store typmod anyway for some of the datetime functions. + * Note that currently, all variants return non-collating datatypes, so we do + * not need a collation field; also, all these functions are stable. + */ +typedef enum SQLValueFunctionOp +{ + SVFOP_CURRENT_DATE, + SVFOP_CURRENT_TIME, + SVFOP_CURRENT_TIME_N, + SVFOP_CURRENT_TIMESTAMP, + SVFOP_CURRENT_TIMESTAMP_N, + SVFOP_LOCALTIME, + SVFOP_LOCALTIME_N, + SVFOP_LOCALTIMESTAMP, + SVFOP_LOCALTIMESTAMP_N, + SVFOP_CURRENT_ROLE, + SVFOP_CURRENT_USER, + SVFOP_USER, + SVFOP_SESSION_USER, + SVFOP_CURRENT_CATALOG, + SVFOP_CURRENT_SCHEMA +} SQLValueFunctionOp; + +typedef struct SQLValueFunction +{ + Expr xpr; + SQLValueFunctionOp op; /* which function this is */ + /* + * Result type/typmod. Type is fully determined by "op", so no need to + * include this Oid in the query jumbling. + */ + Oid type pg_node_attr(query_jumble_ignore); + int32 typmod; + int location; /* token location, or -1 if unknown */ +} SQLValueFunction; + +/* * XmlExpr - various SQL/XML functions requiring special grammar productions * * 'name' carries the "NAME foo" argument (already XML-escaped). |