|
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
|
*
|
|
|
|
|
* plancat.c
|
|
|
|
|
* routines for accessing the system catalogs
|
|
|
|
|
*
|
|
|
|
|
*
|
|
|
|
|
* Portions Copyright (c) 1996-2018, PostgreSQL Global Development Group
|
|
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
|
|
|
|
*
|
|
|
|
|
*
|
|
|
|
|
* IDENTIFICATION
|
|
|
|
|
* src/backend/optimizer/util/plancat.c
|
|
|
|
|
*
|
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
|
*/
|
|
|
|
|
#include "postgres.h"
|
|
|
|
|
|
|
|
|
|
#include <math.h>
|
|
|
|
|
|
|
|
|
|
#include "access/genam.h"
|
|
|
|
|
#include "access/heapam.h"
|
|
|
|
|
#include "access/htup_details.h"
|
Redesign the planner's handling of index-descent cost estimation.
Historically we've used a couple of very ad-hoc fudge factors to try to
get the right results when indexes of different sizes would satisfy a
query with the same number of index leaf tuples being visited. In
commit 21a39de5809cd3050a37d2554323cc1d0cbeed9d I tweaked one of these
fudge factors, with results that proved disastrous for larger indexes.
Commit bf01e34b556ff37982ba2d882db424aa484c0d07 fudged it some more,
but still with not a lot of principle behind it.
What seems like a better way to address these issues is to explicitly model
index-descent costs, since that's what's really at stake when considering
diferent indexes with similar leaf-page-level costs. We tried that once
long ago, and found that charging random_page_cost per page descended
through was way too much, because upper btree levels tend to stay in cache
in real-world workloads. However, there's still CPU costs to think about,
and the previous fudge factors can be seen as a crude attempt to account
for those costs. So this patch replaces those fudge factors with explicit
charges for the number of tuple comparisons needed to descend the index
tree, plus a small charge per page touched in the descent. The cost
multipliers are chosen so that the resulting charges are in the vicinity of
the historical (pre-9.2) fudge factors for indexes of up to about a million
tuples, while not ballooning unreasonably beyond that, as the old fudge
factor did (even more so in 9.2).
To make this work accurately for btree indexes, add some code that allows
extraction of the known root-page height from a btree. There's no
equivalent number readily available for other index types, but we can use
the log of the number of index pages as an approximate substitute.
This seems like too much of a behavioral change to risk back-patching,
but it should improve matters going forward. In 9.2 I'll just revert
the fudge-factor change.
13 years ago
|
|
|
#include "access/nbtree.h"
|
|
|
|
|
#include "access/sysattr.h"
|
|
|
|
|
#include "access/transam.h"
|
|
|
|
|
#include "access/xlog.h"
|
|
|
|
|
#include "catalog/catalog.h"
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
10 years ago
|
|
|
#include "catalog/dependency.h"
|
|
|
|
|
#include "catalog/heap.h"
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
9 years ago
|
|
|
#include "catalog/partition.h"
|
Restructure index access method API to hide most of it at the C level.
This patch reduces pg_am to just two columns, a name and a handler
function. All the data formerly obtained from pg_am is now provided
in a C struct returned by the handler function. This is similar to
the designs we've adopted for FDWs and tablesample methods. There
are multiple advantages. For one, the index AM's support functions
are now simple C functions, making them faster to call and much less
error-prone, since the C compiler can now check function signatures.
For another, this will make it far more practical to define index access
methods in installable extensions.
A disadvantage is that SQL-level code can no longer see attributes
of index AMs; in particular, some of the crosschecks in the opr_sanity
regression test are no longer possible from SQL. We've addressed that
by adding a facility for the index AM to perform such checks instead.
(Much more could be done in that line, but for now we're content if the
amvalidate functions more or less replace what opr_sanity used to do.)
We might also want to expose some sort of reporting functionality, but
this patch doesn't do that.
Alexander Korotkov, reviewed by Petr Jelínek, and rather heavily
editorialized on by me.
10 years ago
|
|
|
#include "catalog/pg_am.h"
|
Implement multivariate n-distinct coefficients
Add support for explicitly declared statistic objects (CREATE
STATISTICS), allowing collection of statistics on more complex
combinations that individual table columns. Companion commands DROP
STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are
added too. All this DDL has been designed so that more statistic types
can be added later on, such as multivariate most-common-values and
multivariate histograms between columns of a single table, leaving room
for permitting columns on multiple tables, too, as well as expressions.
This commit only adds support for collection of n-distinct coefficient
on user-specified sets of columns in a single table. This is useful to
estimate number of distinct groups in GROUP BY and DISTINCT clauses;
estimation errors there can cause over-allocation of memory in hashed
aggregates, for instance, so it's a worthwhile problem to solve. A new
special pseudo-type pg_ndistinct is used.
(num-distinct estimation was deemed sufficiently useful by itself that
this is worthwhile even if no further statistic types are added
immediately; so much so that another version of essentially the same
functionality was submitted by Kyotaro Horiguchi:
https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp
though this commit does not use that code.)
Author: Tomas Vondra. Some code rework by Álvaro.
Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes,
Ideriha Takeshi
Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz
https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
8 years ago
|
|
|
#include "catalog/pg_statistic_ext.h"
|
|
|
|
|
#include "foreign/fdwapi.h"
|
|
|
|
|
#include "miscadmin.h"
|
|
|
|
|
#include "nodes/makefuncs.h"
|
|
|
|
|
#include "optimizer/clauses.h"
|
|
|
|
|
#include "optimizer/cost.h"
|
|
|
|
|
#include "optimizer/plancat.h"
|
|
|
|
|
#include "optimizer/predtest.h"
|
|
|
|
|
#include "optimizer/prep.h"
|
|
|
|
|
#include "partitioning/partbounds.h"
|
|
|
|
|
#include "parser/parse_relation.h"
|
|
|
|
|
#include "parser/parsetree.h"
|
|
|
|
|
#include "rewrite/rewriteManip.h"
|
Implement multivariate n-distinct coefficients
Add support for explicitly declared statistic objects (CREATE
STATISTICS), allowing collection of statistics on more complex
combinations that individual table columns. Companion commands DROP
STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are
added too. All this DDL has been designed so that more statistic types
can be added later on, such as multivariate most-common-values and
multivariate histograms between columns of a single table, leaving room
for permitting columns on multiple tables, too, as well as expressions.
This commit only adds support for collection of n-distinct coefficient
on user-specified sets of columns in a single table. This is useful to
estimate number of distinct groups in GROUP BY and DISTINCT clauses;
estimation errors there can cause over-allocation of memory in hashed
aggregates, for instance, so it's a worthwhile problem to solve. A new
special pseudo-type pg_ndistinct is used.
(num-distinct estimation was deemed sufficiently useful by itself that
this is worthwhile even if no further statistic types are added
immediately; so much so that another version of essentially the same
functionality was submitted by Kyotaro Horiguchi:
https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp
though this commit does not use that code.)
Author: Tomas Vondra. Some code rework by Álvaro.
Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes,
Ideriha Takeshi
Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz
https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
8 years ago
|
|
|
#include "statistics/statistics.h"
|
|
|
|
|
#include "storage/bufmgr.h"
|
Implement multivariate n-distinct coefficients
Add support for explicitly declared statistic objects (CREATE
STATISTICS), allowing collection of statistics on more complex
combinations that individual table columns. Companion commands DROP
STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are
added too. All this DDL has been designed so that more statistic types
can be added later on, such as multivariate most-common-values and
multivariate histograms between columns of a single table, leaving room
for permitting columns on multiple tables, too, as well as expressions.
This commit only adds support for collection of n-distinct coefficient
on user-specified sets of columns in a single table. This is useful to
estimate number of distinct groups in GROUP BY and DISTINCT clauses;
estimation errors there can cause over-allocation of memory in hashed
aggregates, for instance, so it's a worthwhile problem to solve. A new
special pseudo-type pg_ndistinct is used.
(num-distinct estimation was deemed sufficiently useful by itself that
this is worthwhile even if no further statistic types are added
immediately; so much so that another version of essentially the same
functionality was submitted by Kyotaro Horiguchi:
https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp
though this commit does not use that code.)
Author: Tomas Vondra. Some code rework by Álvaro.
Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes,
Ideriha Takeshi
Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz
https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
8 years ago
|
|
|
#include "utils/builtins.h"
|
|
|
|
|
#include "utils/lsyscache.h"
|
|
|
|
|
#include "utils/partcache.h"
|
|
|
|
|
#include "utils/rel.h"
|
|
|
|
|
#include "utils/syscache.h"
|
|
|
|
|
#include "utils/snapmgr.h"
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/* GUC parameter */
|
|
|
|
|
int constraint_exclusion = CONSTRAINT_EXCLUSION_PARTITION;
|
|
|
|
|
|
|
|
|
|
/* Hook for plugins to get control in get_relation_info() */
|
|
|
|
|
get_relation_info_hook_type get_relation_info_hook = NULL;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
static void get_relation_foreign_keys(PlannerInfo *root, RelOptInfo *rel,
|
|
|
|
|
Relation relation, bool inhparent);
|
|
|
|
|
static bool infer_collation_opclass_match(InferenceElem *elem, Relation idxRel,
|
|
|
|
|
List *idxExprs);
|
|
|
|
|
static int32 get_rel_data_width(Relation rel, int32 *attr_widths);
|
|
|
|
|
static List *get_relation_constraints(PlannerInfo *root,
|
|
|
|
|
Oid relationObjectId, RelOptInfo *rel,
|
|
|
|
|
bool include_notnull);
|
|
|
|
|
static List *build_index_tlist(PlannerInfo *root, IndexOptInfo *index,
|
|
|
|
|
Relation heapRelation);
|
Implement multivariate n-distinct coefficients
Add support for explicitly declared statistic objects (CREATE
STATISTICS), allowing collection of statistics on more complex
combinations that individual table columns. Companion commands DROP
STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are
added too. All this DDL has been designed so that more statistic types
can be added later on, such as multivariate most-common-values and
multivariate histograms between columns of a single table, leaving room
for permitting columns on multiple tables, too, as well as expressions.
This commit only adds support for collection of n-distinct coefficient
on user-specified sets of columns in a single table. This is useful to
estimate number of distinct groups in GROUP BY and DISTINCT clauses;
estimation errors there can cause over-allocation of memory in hashed
aggregates, for instance, so it's a worthwhile problem to solve. A new
special pseudo-type pg_ndistinct is used.
(num-distinct estimation was deemed sufficiently useful by itself that
this is worthwhile even if no further statistic types are added
immediately; so much so that another version of essentially the same
functionality was submitted by Kyotaro Horiguchi:
https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp
though this commit does not use that code.)
Author: Tomas Vondra. Some code rework by Álvaro.
Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes,
Ideriha Takeshi
Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz
https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
8 years ago
|
|
|
static List *get_relation_statistics(RelOptInfo *rel, Relation relation);
|
|
|
|
|
static void set_relation_partition_info(PlannerInfo *root, RelOptInfo *rel,
|
|
|
|
|
Relation relation);
|
|
|
|
|
static PartitionScheme find_partition_scheme(PlannerInfo *root, Relation rel);
|
Basic partition-wise join functionality.
Instead of joining two partitioned tables in their entirety we can, if
it is an equi-join on the partition keys, join the matching partitions
individually. This involves teaching the planner about "other join"
rels, which are related to regular join rels in the same way that
other member rels are related to baserels. This can use significantly
more CPU time and memory than regular join planning, because there may
now be a set of "other" rels not only for every base relation but also
for every join relation. In most practical cases, this probably
shouldn't be a problem, because (1) it's probably unusual to join many
tables each with many partitions using the partition keys for all
joins and (2) if you do that scenario then you probably have a big
enough machine to handle the increased memory cost of planning and (3)
the resulting plan is highly likely to be better, so what you spend in
planning you'll make up on the execution side. All the same, for now,
turn this feature off by default.
Currently, we can only perform joins between two tables whose
partitioning schemes are absolutely identical. It would be nice to
cope with other scenarios, such as extra partitions on one side or the
other with no match on the other side, but that will have to wait for
a future patch.
Ashutosh Bapat, reviewed and tested by Rajkumar Raghuwanshi, Amit
Langote, Rafia Sabih, Thomas Munro, Dilip Kumar, Antonin Houska, Amit
Khandekar, and by me. A few final adjustments by me.
Discussion: http://postgr.es/m/CAFjFpRfQ8GrQvzp3jA2wnLqrHmaXna-urjm_UY9BqXj=EaDTSA@mail.gmail.com
Discussion: http://postgr.es/m/CAFjFpRcitjfrULr5jfuKWRPsGUX0LQ0k8-yG0Qw2+1LBGNpMdw@mail.gmail.com
8 years ago
|
|
|
static void set_baserel_partition_key_exprs(Relation relation,
|
|
|
|
|
RelOptInfo *rel);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* get_relation_info -
|
|
|
|
|
* Retrieves catalog information for a given relation.
|
|
|
|
|
*
|
|
|
|
|
* Given the Oid of the relation, return the following info into fields
|
|
|
|
|
* of the RelOptInfo struct:
|
|
|
|
|
*
|
|
|
|
|
* min_attr lowest valid AttrNumber
|
|
|
|
|
* max_attr highest valid AttrNumber
|
|
|
|
|
* indexlist list of IndexOptInfos for relation's indexes
|
|
|
|
|
* statlist list of StatisticExtInfo for relation's statistic objects
|
|
|
|
|
* serverid if it's a foreign table, the server OID
|
|
|
|
|
* fdwroutine if it's a foreign table, the FDW function pointers
|
|
|
|
|
* pages number of pages
|
|
|
|
|
* tuples number of tuples
|
|
|
|
|
* rel_parallel_workers user-defined number of parallel workers
|
|
|
|
|
*
|
|
|
|
|
* Also, add information about the relation's foreign keys to root->fkey_list.
|
|
|
|
|
*
|
|
|
|
|
* Also, initialize the attr_needed[] and attr_widths[] arrays. In most
|
|
|
|
|
* cases these are left as zeroes, but sometimes we need to compute attr
|
|
|
|
|
* widths here, and we may as well cache the results for costsize.c.
|
|
|
|
|
*
|
|
|
|
|
* If inhparent is true, all we need to do is set up the attr arrays:
|
|
|
|
|
* the RelOptInfo actually represents the appendrel formed by an inheritance
|
|
|
|
|
* tree, and so the parent rel's physical size and index information isn't
|
|
|
|
|
* important for it.
|
|
|
|
|
*/
|
|
|
|
|
void
|
|
|
|
|
get_relation_info(PlannerInfo *root, Oid relationObjectId, bool inhparent,
|
|
|
|
|
RelOptInfo *rel)
|
|
|
|
|
{
|
|
|
|
|
Index varno = rel->relid;
|
|
|
|
|
Relation relation;
|
|
|
|
|
bool hasindex;
|
|
|
|
|
List *indexinfos = NIL;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* We need not lock the relation since it was already locked, either by
|
|
|
|
|
* the rewriter or when expand_inherited_rtentry() added it to the query's
|
|
|
|
|
* rangetable.
|
|
|
|
|
*/
|
|
|
|
|
relation = heap_open(relationObjectId, NoLock);
|
|
|
|
|
|
|
|
|
|
/* Temporary and unlogged relations are inaccessible during recovery. */
|
|
|
|
|
if (!RelationNeedsWAL(relation) && RecoveryInProgress())
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
|
|
|
|
|
errmsg("cannot access temporary or unlogged relations during recovery")));
|
|
|
|
|
|
|
|
|
|
rel->min_attr = FirstLowInvalidHeapAttributeNumber + 1;
|
|
|
|
|
rel->max_attr = RelationGetNumberOfAttributes(relation);
|
|
|
|
|
rel->reltablespace = RelationGetForm(relation)->reltablespace;
|
|
|
|
|
|
|
|
|
|
Assert(rel->max_attr >= rel->min_attr);
|
|
|
|
|
rel->attr_needed = (Relids *)
|
|
|
|
|
palloc0((rel->max_attr - rel->min_attr + 1) * sizeof(Relids));
|
|
|
|
|
rel->attr_widths = (int32 *)
|
|
|
|
|
palloc0((rel->max_attr - rel->min_attr + 1) * sizeof(int32));
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Estimate relation size --- unless it's an inheritance parent, in which
|
|
|
|
|
* case the size we want is not the rel's own size but the size of its
|
|
|
|
|
* inheritance tree. That will be computed in set_append_rel_size().
|
|
|
|
|
*/
|
|
|
|
|
if (!inhparent)
|
|
|
|
|
estimate_rel_size(relation, rel->attr_widths - rel->min_attr,
|
|
|
|
|
&rel->pages, &rel->tuples, &rel->allvisfrac);
|
|
|
|
|
|
|
|
|
|
/* Retrieve the parallel_workers reloption, or -1 if not set. */
|
|
|
|
|
rel->rel_parallel_workers = RelationGetParallelWorkers(relation, -1);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Make list of indexes. Ignore indexes on system catalogs if told to.
|
|
|
|
|
* Don't bother with indexes for an inheritance parent, either.
|
|
|
|
|
*/
|
|
|
|
|
if (inhparent ||
|
Refine our definition of what constitutes a system relation.
Although user-defined relations can't be directly created in
pg_catalog, it's possible for them to end up there, because you can
create them in some other schema and then use ALTER TABLE .. SET SCHEMA
to move them there. Previously, such relations couldn't afterwards
be manipulated, because IsSystemRelation()/IsSystemClass() rejected
all attempts to modify objects in the pg_catalog schema, regardless
of their origin. With this patch, they now reject only those
objects in pg_catalog which were created at initdb-time, allowing
most operations on user-created tables in pg_catalog to proceed
normally.
This patch also adds new functions IsCatalogRelation() and
IsCatalogClass(), which is similar to IsSystemRelation() and
IsSystemClass() but with a slightly narrower definition: only TOAST
tables of system catalogs are included, rather than *all* TOAST tables.
This is currently used only for making decisions about when
invalidation messages need to be sent, but upcoming logical decoding
patches will find other uses for this information.
Andres Freund, with some modifications by me.
12 years ago
|
|
|
(IgnoreSystemIndexes && IsSystemRelation(relation)))
|
|
|
|
|
hasindex = false;
|
|
|
|
|
else
|
|
|
|
|
hasindex = relation->rd_rel->relhasindex;
|
|
|
|
|
|
|
|
|
|
if (hasindex)
|
|
|
|
|
{
|
|
|
|
|
List *indexoidlist;
|
|
|
|
|
ListCell *l;
|
|
|
|
|
LOCKMODE lmode;
|
|
|
|
|
|
|
|
|
|
indexoidlist = RelationGetIndexList(relation);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* For each index, we get the same type of lock that the executor will
|
|
|
|
|
* need, and do not release it. This saves a couple of trips to the
|
|
|
|
|
* shared lock manager while not creating any real loss of
|
|
|
|
|
* concurrency, because no schema changes could be happening on the
|
|
|
|
|
* index while we hold lock on the parent rel, and neither lock type
|
|
|
|
|
* blocks any other kind of index operation.
|
|
|
|
|
*/
|
|
|
|
|
if (rel->relid == root->parse->resultRelation)
|
|
|
|
|
lmode = RowExclusiveLock;
|
|
|
|
|
else
|
|
|
|
|
lmode = AccessShareLock;
|
|
|
|
|
|
|
|
|
|
foreach(l, indexoidlist)
|
|
|
|
|
{
|
|
|
|
|
Oid indexoid = lfirst_oid(l);
|
|
|
|
|
Relation indexRelation;
|
|
|
|
|
Form_pg_index index;
|
Restructure index access method API to hide most of it at the C level.
This patch reduces pg_am to just two columns, a name and a handler
function. All the data formerly obtained from pg_am is now provided
in a C struct returned by the handler function. This is similar to
the designs we've adopted for FDWs and tablesample methods. There
are multiple advantages. For one, the index AM's support functions
are now simple C functions, making them faster to call and much less
error-prone, since the C compiler can now check function signatures.
For another, this will make it far more practical to define index access
methods in installable extensions.
A disadvantage is that SQL-level code can no longer see attributes
of index AMs; in particular, some of the crosschecks in the opr_sanity
regression test are no longer possible from SQL. We've addressed that
by adding a facility for the index AM to perform such checks instead.
(Much more could be done in that line, but for now we're content if the
amvalidate functions more or less replace what opr_sanity used to do.)
We might also want to expose some sort of reporting functionality, but
this patch doesn't do that.
Alexander Korotkov, reviewed by Petr Jelínek, and rather heavily
editorialized on by me.
10 years ago
|
|
|
IndexAmRoutine *amroutine;
|
|
|
|
|
IndexOptInfo *info;
|
|
|
|
|
int ncolumns,
|
|
|
|
|
nkeycolumns;
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Extract info from the relation descriptor for the index.
|
|
|
|
|
*/
|
|
|
|
|
indexRelation = index_open(indexoid, lmode);
|
|
|
|
|
index = indexRelation->rd_index;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Ignore invalid indexes, since they can't safely be used for
|
|
|
|
|
* queries. Note that this is OK because the data structure we
|
|
|
|
|
* are constructing is only used by the planner --- the executor
|
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP
INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor
choice of catalog state representation. The pg_index state for an index
that's reached the final pre-drop stage was the same as the state for an
index just created by CREATE INDEX CONCURRENTLY. This meant that the
(necessary) change to make RelationGetIndexList ignore about-to-die indexes
also made it ignore freshly-created indexes; which is catastrophic because
the latter do need to be considered in HOT-safety decisions. Failure to
do so leads to incorrect index entries and subsequently wrong results from
queries depending on the concurrently-created index.
To fix, add an additional boolean column "indislive" to pg_index, so that
the freshly-created and about-to-die states can be distinguished. (This
change obviously is only possible in HEAD. This patch will need to be
back-patched, but in 9.2 we'll use a kluge consisting of overloading the
formerly-impossible state of indisvalid = true and indisready = false.)
In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index
flag changes they make without exclusive lock on the index are made via
heap_inplace_update() rather than a normal transactional update. The
latter is not very safe because moving the pg_index tuple could result in
concurrent SnapshotNow scans finding it twice or not at all, thus possibly
resulting in index corruption. This is a pre-existing bug in CREATE INDEX
CONCURRENTLY, which was copied into the DROP code.
In addition, fix various places in the code that ought to check to make
sure that the indexes they are manipulating are valid and/or ready as
appropriate. These represent bugs that have existed since 8.2, since
a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid
index behind, and we ought not try to do anything that might fail with
such an index.
Also fix RelationReloadIndexInfo to ensure it copies all the pg_index
columns that are allowed to change after initial creation. Previously we
could have been left with stale values of some fields in an index relcache
entry. It's not clear whether this actually had any user-visible
consequences, but it's at least a bug waiting to happen.
In addition, do some code and docs review for DROP INDEX CONCURRENTLY;
some cosmetic code cleanup but mostly addition and revision of comments.
This will need to be back-patched, but in a noticeably different form,
so I'm committing it to HEAD before working on the back-patch.
Problem reported by Amit Kapila, diagnosis by Pavan Deolassee,
fix by Tom Lane and Andres Freund.
13 years ago
|
|
|
* still needs to insert into "invalid" indexes, if they're marked
|
|
|
|
|
* IndexIsReady.
|
|
|
|
|
*/
|
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP
INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor
choice of catalog state representation. The pg_index state for an index
that's reached the final pre-drop stage was the same as the state for an
index just created by CREATE INDEX CONCURRENTLY. This meant that the
(necessary) change to make RelationGetIndexList ignore about-to-die indexes
also made it ignore freshly-created indexes; which is catastrophic because
the latter do need to be considered in HOT-safety decisions. Failure to
do so leads to incorrect index entries and subsequently wrong results from
queries depending on the concurrently-created index.
To fix, add an additional boolean column "indislive" to pg_index, so that
the freshly-created and about-to-die states can be distinguished. (This
change obviously is only possible in HEAD. This patch will need to be
back-patched, but in 9.2 we'll use a kluge consisting of overloading the
formerly-impossible state of indisvalid = true and indisready = false.)
In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index
flag changes they make without exclusive lock on the index are made via
heap_inplace_update() rather than a normal transactional update. The
latter is not very safe because moving the pg_index tuple could result in
concurrent SnapshotNow scans finding it twice or not at all, thus possibly
resulting in index corruption. This is a pre-existing bug in CREATE INDEX
CONCURRENTLY, which was copied into the DROP code.
In addition, fix various places in the code that ought to check to make
sure that the indexes they are manipulating are valid and/or ready as
appropriate. These represent bugs that have existed since 8.2, since
a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid
index behind, and we ought not try to do anything that might fail with
such an index.
Also fix RelationReloadIndexInfo to ensure it copies all the pg_index
columns that are allowed to change after initial creation. Previously we
could have been left with stale values of some fields in an index relcache
entry. It's not clear whether this actually had any user-visible
consequences, but it's at least a bug waiting to happen.
In addition, do some code and docs review for DROP INDEX CONCURRENTLY;
some cosmetic code cleanup but mostly addition and revision of comments.
This will need to be back-patched, but in a noticeably different form,
so I'm committing it to HEAD before working on the back-patch.
Problem reported by Amit Kapila, diagnosis by Pavan Deolassee,
fix by Tom Lane and Andres Freund.
13 years ago
|
|
|
if (!IndexIsValid(index))
|
|
|
|
|
{
|
|
|
|
|
index_close(indexRelation, NoLock);
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Ignore partitioned indexes, since they are not usable for
|
|
|
|
|
* queries.
|
|
|
|
|
*/
|
|
|
|
|
if (indexRelation->rd_rel->relkind == RELKIND_PARTITIONED_INDEX)
|
|
|
|
|
{
|
|
|
|
|
index_close(indexRelation, NoLock);
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* If the index is valid, but cannot yet be used, ignore it; but
|
|
|
|
|
* mark the plan we are generating as transient. See
|
|
|
|
|
* src/backend/access/heap/README.HOT for discussion.
|
|
|
|
|
*/
|
|
|
|
|
if (index->indcheckxmin &&
|
|
|
|
|
!TransactionIdPrecedes(HeapTupleHeaderGetXmin(indexRelation->rd_indextuple->t_data),
|
|
|
|
|
TransactionXmin))
|
|
|
|
|
{
|
|
|
|
|
root->glob->transientPlan = true;
|
|
|
|
|
index_close(indexRelation, NoLock);
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
info = makeNode(IndexOptInfo);
|
|
|
|
|
|
|
|
|
|
info->indexoid = index->indexrelid;
|
|
|
|
|
info->reltablespace =
|
|
|
|
|
RelationGetForm(indexRelation)->reltablespace;
|
|
|
|
|
info->rel = rel;
|
|
|
|
|
info->ncolumns = ncolumns = index->indnatts;
|
|
|
|
|
info->nkeycolumns = nkeycolumns = index->indnkeyatts;
|
|
|
|
|
|
|
|
|
|
info->indexkeys = (int *) palloc(sizeof(int) * ncolumns);
|
|
|
|
|
info->indexcollations = (Oid *) palloc(sizeof(Oid) * nkeycolumns);
|
|
|
|
|
info->opfamily = (Oid *) palloc(sizeof(Oid) * nkeycolumns);
|
|
|
|
|
info->opcintype = (Oid *) palloc(sizeof(Oid) * nkeycolumns);
|
|
|
|
|
info->canreturn = (bool *) palloc(sizeof(bool) * ncolumns);
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < ncolumns; i++)
|
|
|
|
|
{
|
|
|
|
|
info->indexkeys[i] = index->indkey.values[i];
|
|
|
|
|
info->canreturn[i] = index_can_return(indexRelation, i + 1);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < nkeycolumns; i++)
|
|
|
|
|
{
|
|
|
|
|
info->opfamily[i] = indexRelation->rd_opfamily[i];
|
|
|
|
|
info->opcintype[i] = indexRelation->rd_opcintype[i];
|
|
|
|
|
info->indexcollations[i] = indexRelation->rd_indcollation[i];
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
info->relam = indexRelation->rd_rel->relam;
|
Restructure index access method API to hide most of it at the C level.
This patch reduces pg_am to just two columns, a name and a handler
function. All the data formerly obtained from pg_am is now provided
in a C struct returned by the handler function. This is similar to
the designs we've adopted for FDWs and tablesample methods. There
are multiple advantages. For one, the index AM's support functions
are now simple C functions, making them faster to call and much less
error-prone, since the C compiler can now check function signatures.
For another, this will make it far more practical to define index access
methods in installable extensions.
A disadvantage is that SQL-level code can no longer see attributes
of index AMs; in particular, some of the crosschecks in the opr_sanity
regression test are no longer possible from SQL. We've addressed that
by adding a facility for the index AM to perform such checks instead.
(Much more could be done in that line, but for now we're content if the
amvalidate functions more or less replace what opr_sanity used to do.)
We might also want to expose some sort of reporting functionality, but
this patch doesn't do that.
Alexander Korotkov, reviewed by Petr Jelínek, and rather heavily
editorialized on by me.
10 years ago
|
|
|
|
|
|
|
|
/* We copy just the fields we need, not all of rd_amroutine */
|
|
|
|
|
amroutine = indexRelation->rd_amroutine;
|
|
|
|
|
info->amcanorderbyop = amroutine->amcanorderbyop;
|
|
|
|
|
info->amoptionalkey = amroutine->amoptionalkey;
|
|
|
|
|
info->amsearcharray = amroutine->amsearcharray;
|
|
|
|
|
info->amsearchnulls = amroutine->amsearchnulls;
|
|
|
|
|
info->amcanparallel = amroutine->amcanparallel;
|
Restructure index access method API to hide most of it at the C level.
This patch reduces pg_am to just two columns, a name and a handler
function. All the data formerly obtained from pg_am is now provided
in a C struct returned by the handler function. This is similar to
the designs we've adopted for FDWs and tablesample methods. There
are multiple advantages. For one, the index AM's support functions
are now simple C functions, making them faster to call and much less
error-prone, since the C compiler can now check function signatures.
For another, this will make it far more practical to define index access
methods in installable extensions.
A disadvantage is that SQL-level code can no longer see attributes
of index AMs; in particular, some of the crosschecks in the opr_sanity
regression test are no longer possible from SQL. We've addressed that
by adding a facility for the index AM to perform such checks instead.
(Much more could be done in that line, but for now we're content if the
amvalidate functions more or less replace what opr_sanity used to do.)
We might also want to expose some sort of reporting functionality, but
this patch doesn't do that.
Alexander Korotkov, reviewed by Petr Jelínek, and rather heavily
editorialized on by me.
10 years ago
|
|
|
info->amhasgettuple = (amroutine->amgettuple != NULL);
|
|
|
|
|
info->amhasgetbitmap = (amroutine->amgetbitmap != NULL);
|
|
|
|
|
info->amcostestimate = amroutine->amcostestimate;
|
|
|
|
|
Assert(info->amcostestimate != NULL);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Fetch the ordering information for the index, if any.
|
|
|
|
|
*/
|
|
|
|
|
if (info->relam == BTREE_AM_OID)
|
|
|
|
|
{
|
|
|
|
|
/*
|
|
|
|
|
* If it's a btree index, we can use its opfamily OIDs
|
|
|
|
|
* directly as the sort ordering opfamily OIDs.
|
|
|
|
|
*/
|
Restructure index access method API to hide most of it at the C level.
This patch reduces pg_am to just two columns, a name and a handler
function. All the data formerly obtained from pg_am is now provided
in a C struct returned by the handler function. This is similar to
the designs we've adopted for FDWs and tablesample methods. There
are multiple advantages. For one, the index AM's support functions
are now simple C functions, making them faster to call and much less
error-prone, since the C compiler can now check function signatures.
For another, this will make it far more practical to define index access
methods in installable extensions.
A disadvantage is that SQL-level code can no longer see attributes
of index AMs; in particular, some of the crosschecks in the opr_sanity
regression test are no longer possible from SQL. We've addressed that
by adding a facility for the index AM to perform such checks instead.
(Much more could be done in that line, but for now we're content if the
amvalidate functions more or less replace what opr_sanity used to do.)
We might also want to expose some sort of reporting functionality, but
this patch doesn't do that.
Alexander Korotkov, reviewed by Petr Jelínek, and rather heavily
editorialized on by me.
10 years ago
|
|
|
Assert(amroutine->amcanorder);
|
|
|
|
|
|
|
|
|
|
info->sortopfamily = info->opfamily;
|
|
|
|
|
info->reverse_sort = (bool *) palloc(sizeof(bool) * nkeycolumns);
|
|
|
|
|
info->nulls_first = (bool *) palloc(sizeof(bool) * nkeycolumns);
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < nkeycolumns; i++)
|
|
|
|
|
{
|
|
|
|
|
int16 opt = indexRelation->rd_indoption[i];
|
|
|
|
|
|
|
|
|
|
info->reverse_sort[i] = (opt & INDOPTION_DESC) != 0;
|
|
|
|
|
info->nulls_first[i] = (opt & INDOPTION_NULLS_FIRST) != 0;
|
|
|
|
|
}
|
|
|
|
|
}
|
Restructure index access method API to hide most of it at the C level.
This patch reduces pg_am to just two columns, a name and a handler
function. All the data formerly obtained from pg_am is now provided
in a C struct returned by the handler function. This is similar to
the designs we've adopted for FDWs and tablesample methods. There
are multiple advantages. For one, the index AM's support functions
are now simple C functions, making them faster to call and much less
error-prone, since the C compiler can now check function signatures.
For another, this will make it far more practical to define index access
methods in installable extensions.
A disadvantage is that SQL-level code can no longer see attributes
of index AMs; in particular, some of the crosschecks in the opr_sanity
regression test are no longer possible from SQL. We've addressed that
by adding a facility for the index AM to perform such checks instead.
(Much more could be done in that line, but for now we're content if the
amvalidate functions more or less replace what opr_sanity used to do.)
We might also want to expose some sort of reporting functionality, but
this patch doesn't do that.
Alexander Korotkov, reviewed by Petr Jelínek, and rather heavily
editorialized on by me.
10 years ago
|
|
|
else if (amroutine->amcanorder)
|
|
|
|
|
{
|
|
|
|
|
/*
|
|
|
|
|
* Otherwise, identify the corresponding btree opfamilies by
|
|
|
|
|
* trying to map this index's "<" operators into btree. Since
|
|
|
|
|
* "<" uniquely defines the behavior of a sort order, this is
|
|
|
|
|
* a sufficient test.
|
|
|
|
|
*
|
|
|
|
|
* XXX This method is rather slow and also requires the
|
|
|
|
|
* undesirable assumption that the other index AM numbers its
|
|
|
|
|
* strategies the same as btree. It'd be better to have a way
|
|
|
|
|
* to explicitly declare the corresponding btree opfamily for
|
|
|
|
|
* each opfamily of the other index type. But given the lack
|
|
|
|
|
* of current or foreseeable amcanorder index types, it's not
|
|
|
|
|
* worth expending more effort on now.
|
|
|
|
|
*/
|
|
|
|
|
info->sortopfamily = (Oid *) palloc(sizeof(Oid) * nkeycolumns);
|
|
|
|
|
info->reverse_sort = (bool *) palloc(sizeof(bool) * nkeycolumns);
|
|
|
|
|
info->nulls_first = (bool *) palloc(sizeof(bool) * nkeycolumns);
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < nkeycolumns; i++)
|
|
|
|
|
{
|
|
|
|
|
int16 opt = indexRelation->rd_indoption[i];
|
|
|
|
|
Oid ltopr;
|
|
|
|
|
Oid btopfamily;
|
|
|
|
|
Oid btopcintype;
|
|
|
|
|
int16 btstrategy;
|
|
|
|
|
|
|
|
|
|
info->reverse_sort[i] = (opt & INDOPTION_DESC) != 0;
|
|
|
|
|
info->nulls_first[i] = (opt & INDOPTION_NULLS_FIRST) != 0;
|
|
|
|
|
|
|
|
|
|
ltopr = get_opfamily_member(info->opfamily[i],
|
|
|
|
|
info->opcintype[i],
|
|
|
|
|
info->opcintype[i],
|
|
|
|
|
BTLessStrategyNumber);
|
|
|
|
|
if (OidIsValid(ltopr) &&
|
|
|
|
|
get_ordering_op_properties(ltopr,
|
|
|
|
|
&btopfamily,
|
|
|
|
|
&btopcintype,
|
|
|
|
|
&btstrategy) &&
|
|
|
|
|
btopcintype == info->opcintype[i] &&
|
|
|
|
|
btstrategy == BTLessStrategyNumber)
|
|
|
|
|
{
|
|
|
|
|
/* Successful mapping */
|
|
|
|
|
info->sortopfamily[i] = btopfamily;
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
/* Fail ... quietly treat index as unordered */
|
|
|
|
|
info->sortopfamily = NULL;
|
|
|
|
|
info->reverse_sort = NULL;
|
|
|
|
|
info->nulls_first = NULL;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
info->sortopfamily = NULL;
|
|
|
|
|
info->reverse_sort = NULL;
|
|
|
|
|
info->nulls_first = NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Fetch the index expressions and predicate, if any. We must
|
|
|
|
|
* modify the copies we obtain from the relcache to have the
|
|
|
|
|
* correct varno for the parent relation, so that they match up
|
|
|
|
|
* correctly against qual clauses.
|
|
|
|
|
*/
|
|
|
|
|
info->indexprs = RelationGetIndexExpressions(indexRelation);
|
|
|
|
|
info->indpred = RelationGetIndexPredicate(indexRelation);
|
|
|
|
|
if (info->indexprs && varno != 1)
|
|
|
|
|
ChangeVarNodes((Node *) info->indexprs, 1, varno, 0);
|
|
|
|
|
if (info->indpred && varno != 1)
|
|
|
|
|
ChangeVarNodes((Node *) info->indpred, 1, varno, 0);
|
|
|
|
|
|
|
|
|
|
/* Build targetlist using the completed indexprs data */
|
|
|
|
|
info->indextlist = build_index_tlist(root, info, relation);
|
|
|
|
|
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
8 years ago
|
|
|
info->indrestrictinfo = NIL; /* set later, in indxpath.c */
|
|
|
|
|
info->predOK = false; /* set later, in indxpath.c */
|
|
|
|
|
info->unique = index->indisunique;
|
|
|
|
|
info->immediate = index->indimmediate;
|
|
|
|
|
info->hypothetical = false;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Estimate the index size. If it's not a partial index, we lock
|
|
|
|
|
* the number-of-tuples estimate to equal the parent table; if it
|
|
|
|
|
* is partial then we have to use the same methods as we would for
|
|
|
|
|
* a table, except we can be sure that the index is not larger
|
|
|
|
|
* than the table.
|
|
|
|
|
*/
|
|
|
|
|
if (info->indpred == NIL)
|
|
|
|
|
{
|
|
|
|
|
info->pages = RelationGetNumberOfBlocks(indexRelation);
|
|
|
|
|
info->tuples = rel->tuples;
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
double allvisfrac; /* dummy */
|
|
|
|
|
|
|
|
|
|
estimate_rel_size(indexRelation, NULL,
|
|
|
|
|
&info->pages, &info->tuples, &allvisfrac);
|
|
|
|
|
if (info->tuples > rel->tuples)
|
|
|
|
|
info->tuples = rel->tuples;
|
|
|
|
|
}
|
|
|
|
|
|
Redesign the planner's handling of index-descent cost estimation.
Historically we've used a couple of very ad-hoc fudge factors to try to
get the right results when indexes of different sizes would satisfy a
query with the same number of index leaf tuples being visited. In
commit 21a39de5809cd3050a37d2554323cc1d0cbeed9d I tweaked one of these
fudge factors, with results that proved disastrous for larger indexes.
Commit bf01e34b556ff37982ba2d882db424aa484c0d07 fudged it some more,
but still with not a lot of principle behind it.
What seems like a better way to address these issues is to explicitly model
index-descent costs, since that's what's really at stake when considering
diferent indexes with similar leaf-page-level costs. We tried that once
long ago, and found that charging random_page_cost per page descended
through was way too much, because upper btree levels tend to stay in cache
in real-world workloads. However, there's still CPU costs to think about,
and the previous fudge factors can be seen as a crude attempt to account
for those costs. So this patch replaces those fudge factors with explicit
charges for the number of tuple comparisons needed to descend the index
tree, plus a small charge per page touched in the descent. The cost
multipliers are chosen so that the resulting charges are in the vicinity of
the historical (pre-9.2) fudge factors for indexes of up to about a million
tuples, while not ballooning unreasonably beyond that, as the old fudge
factor did (even more so in 9.2).
To make this work accurately for btree indexes, add some code that allows
extraction of the known root-page height from a btree. There's no
equivalent number readily available for other index types, but we can use
the log of the number of index pages as an approximate substitute.
This seems like too much of a behavioral change to risk back-patching,
but it should improve matters going forward. In 9.2 I'll just revert
the fudge-factor change.
13 years ago
|
|
|
if (info->relam == BTREE_AM_OID)
|
|
|
|
|
{
|
|
|
|
|
/* For btrees, get tree height while we have the index open */
|
|
|
|
|
info->tree_height = _bt_getrootheight(indexRelation);
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
/* For other index types, just set it to "unknown" for now */
|
|
|
|
|
info->tree_height = -1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
index_close(indexRelation, NoLock);
|
|
|
|
|
|
|
|
|
|
indexinfos = lcons(info, indexinfos);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
list_free(indexoidlist);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
rel->indexlist = indexinfos;
|
|
|
|
|
|
Implement multivariate n-distinct coefficients
Add support for explicitly declared statistic objects (CREATE
STATISTICS), allowing collection of statistics on more complex
combinations that individual table columns. Companion commands DROP
STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are
added too. All this DDL has been designed so that more statistic types
can be added later on, such as multivariate most-common-values and
multivariate histograms between columns of a single table, leaving room
for permitting columns on multiple tables, too, as well as expressions.
This commit only adds support for collection of n-distinct coefficient
on user-specified sets of columns in a single table. This is useful to
estimate number of distinct groups in GROUP BY and DISTINCT clauses;
estimation errors there can cause over-allocation of memory in hashed
aggregates, for instance, so it's a worthwhile problem to solve. A new
special pseudo-type pg_ndistinct is used.
(num-distinct estimation was deemed sufficiently useful by itself that
this is worthwhile even if no further statistic types are added
immediately; so much so that another version of essentially the same
functionality was submitted by Kyotaro Horiguchi:
https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp
though this commit does not use that code.)
Author: Tomas Vondra. Some code rework by Álvaro.
Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes,
Ideriha Takeshi
Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz
https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
8 years ago
|
|
|
rel->statlist = get_relation_statistics(rel, relation);
|
|
|
|
|
|
Code review for foreign/custom join pushdown patch.
Commit e7cb7ee14555cc9c5773e2c102efd6371f6f2005 included some design
decisions that seem pretty questionable to me, and there was quite a lot
of stuff not to like about the documentation and comments. Clean up
as follows:
* Consider foreign joins only between foreign tables on the same server,
rather than between any two foreign tables with the same underlying FDW
handler function. In most if not all cases, the FDW would simply have had
to apply the same-server restriction itself (far more expensively, both for
lack of caching and because it would be repeated for each combination of
input sub-joins), or else risk nasty bugs. Anyone who's really intent on
doing something outside this restriction can always use the
set_join_pathlist_hook.
* Rename fdw_ps_tlist/custom_ps_tlist to fdw_scan_tlist/custom_scan_tlist
to better reflect what they're for, and allow these custom scan tlists
to be used even for base relations.
* Change make_foreignscan() API to include passing the fdw_scan_tlist
value, since the FDW is required to set that. Backwards compatibility
doesn't seem like an adequate reason to expect FDWs to set it in some
ad-hoc extra step, and anyway existing FDWs can just pass NIL.
* Change the API of path-generating subroutines of add_paths_to_joinrel,
and in particular that of GetForeignJoinPaths and set_join_pathlist_hook,
so that various less-used parameters are passed in a struct rather than
as separate parameter-list entries. The objective here is to reduce the
probability that future additions to those parameter lists will result in
source-level API breaks for users of these hooks. It's possible that this
is even a small win for the core code, since most CPU architectures can't
pass more than half a dozen parameters efficiently anyway. I kept root,
joinrel, outerrel, innerrel, and jointype as separate parameters to reduce
code churn in joinpath.c --- in particular, putting jointype into the
struct would have been problematic because of the subroutines' habit of
changing their local copies of that variable.
* Avoid ad-hocery in ExecAssignScanProjectionInfo. It was probably all
right for it to know about IndexOnlyScan, but if the list is to grow
we should refactor the knowledge out to the callers.
* Restore nodeForeignscan.c's previous use of the relcache to avoid
extra GetFdwRoutine lookups for base-relation scans.
* Lots of cleanup of documentation and missed comments. Re-order some
code additions into more logical places.
10 years ago
|
|
|
/* Grab foreign-table info using the relcache, while we have it */
|
|
|
|
|
if (relation->rd_rel->relkind == RELKIND_FOREIGN_TABLE)
|
|
|
|
|
{
|
Code review for foreign/custom join pushdown patch.
Commit e7cb7ee14555cc9c5773e2c102efd6371f6f2005 included some design
decisions that seem pretty questionable to me, and there was quite a lot
of stuff not to like about the documentation and comments. Clean up
as follows:
* Consider foreign joins only between foreign tables on the same server,
rather than between any two foreign tables with the same underlying FDW
handler function. In most if not all cases, the FDW would simply have had
to apply the same-server restriction itself (far more expensively, both for
lack of caching and because it would be repeated for each combination of
input sub-joins), or else risk nasty bugs. Anyone who's really intent on
doing something outside this restriction can always use the
set_join_pathlist_hook.
* Rename fdw_ps_tlist/custom_ps_tlist to fdw_scan_tlist/custom_scan_tlist
to better reflect what they're for, and allow these custom scan tlists
to be used even for base relations.
* Change make_foreignscan() API to include passing the fdw_scan_tlist
value, since the FDW is required to set that. Backwards compatibility
doesn't seem like an adequate reason to expect FDWs to set it in some
ad-hoc extra step, and anyway existing FDWs can just pass NIL.
* Change the API of path-generating subroutines of add_paths_to_joinrel,
and in particular that of GetForeignJoinPaths and set_join_pathlist_hook,
so that various less-used parameters are passed in a struct rather than
as separate parameter-list entries. The objective here is to reduce the
probability that future additions to those parameter lists will result in
source-level API breaks for users of these hooks. It's possible that this
is even a small win for the core code, since most CPU architectures can't
pass more than half a dozen parameters efficiently anyway. I kept root,
joinrel, outerrel, innerrel, and jointype as separate parameters to reduce
code churn in joinpath.c --- in particular, putting jointype into the
struct would have been problematic because of the subroutines' habit of
changing their local copies of that variable.
* Avoid ad-hocery in ExecAssignScanProjectionInfo. It was probably all
right for it to know about IndexOnlyScan, but if the list is to grow
we should refactor the knowledge out to the callers.
* Restore nodeForeignscan.c's previous use of the relcache to avoid
extra GetFdwRoutine lookups for base-relation scans.
* Lots of cleanup of documentation and missed comments. Re-order some
code additions into more logical places.
10 years ago
|
|
|
rel->serverid = GetForeignServerIdByRelId(RelationGetRelid(relation));
|
|
|
|
|
rel->fdwroutine = GetFdwRoutineForRelation(relation, true);
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
Code review for foreign/custom join pushdown patch.
Commit e7cb7ee14555cc9c5773e2c102efd6371f6f2005 included some design
decisions that seem pretty questionable to me, and there was quite a lot
of stuff not to like about the documentation and comments. Clean up
as follows:
* Consider foreign joins only between foreign tables on the same server,
rather than between any two foreign tables with the same underlying FDW
handler function. In most if not all cases, the FDW would simply have had
to apply the same-server restriction itself (far more expensively, both for
lack of caching and because it would be repeated for each combination of
input sub-joins), or else risk nasty bugs. Anyone who's really intent on
doing something outside this restriction can always use the
set_join_pathlist_hook.
* Rename fdw_ps_tlist/custom_ps_tlist to fdw_scan_tlist/custom_scan_tlist
to better reflect what they're for, and allow these custom scan tlists
to be used even for base relations.
* Change make_foreignscan() API to include passing the fdw_scan_tlist
value, since the FDW is required to set that. Backwards compatibility
doesn't seem like an adequate reason to expect FDWs to set it in some
ad-hoc extra step, and anyway existing FDWs can just pass NIL.
* Change the API of path-generating subroutines of add_paths_to_joinrel,
and in particular that of GetForeignJoinPaths and set_join_pathlist_hook,
so that various less-used parameters are passed in a struct rather than
as separate parameter-list entries. The objective here is to reduce the
probability that future additions to those parameter lists will result in
source-level API breaks for users of these hooks. It's possible that this
is even a small win for the core code, since most CPU architectures can't
pass more than half a dozen parameters efficiently anyway. I kept root,
joinrel, outerrel, innerrel, and jointype as separate parameters to reduce
code churn in joinpath.c --- in particular, putting jointype into the
struct would have been problematic because of the subroutines' habit of
changing their local copies of that variable.
* Avoid ad-hocery in ExecAssignScanProjectionInfo. It was probably all
right for it to know about IndexOnlyScan, but if the list is to grow
we should refactor the knowledge out to the callers.
* Restore nodeForeignscan.c's previous use of the relcache to avoid
extra GetFdwRoutine lookups for base-relation scans.
* Lots of cleanup of documentation and missed comments. Re-order some
code additions into more logical places.
10 years ago
|
|
|
rel->serverid = InvalidOid;
|
|
|
|
|
rel->fdwroutine = NULL;
|
|
|
|
|
}
|
Code review for foreign/custom join pushdown patch.
Commit e7cb7ee14555cc9c5773e2c102efd6371f6f2005 included some design
decisions that seem pretty questionable to me, and there was quite a lot
of stuff not to like about the documentation and comments. Clean up
as follows:
* Consider foreign joins only between foreign tables on the same server,
rather than between any two foreign tables with the same underlying FDW
handler function. In most if not all cases, the FDW would simply have had
to apply the same-server restriction itself (far more expensively, both for
lack of caching and because it would be repeated for each combination of
input sub-joins), or else risk nasty bugs. Anyone who's really intent on
doing something outside this restriction can always use the
set_join_pathlist_hook.
* Rename fdw_ps_tlist/custom_ps_tlist to fdw_scan_tlist/custom_scan_tlist
to better reflect what they're for, and allow these custom scan tlists
to be used even for base relations.
* Change make_foreignscan() API to include passing the fdw_scan_tlist
value, since the FDW is required to set that. Backwards compatibility
doesn't seem like an adequate reason to expect FDWs to set it in some
ad-hoc extra step, and anyway existing FDWs can just pass NIL.
* Change the API of path-generating subroutines of add_paths_to_joinrel,
and in particular that of GetForeignJoinPaths and set_join_pathlist_hook,
so that various less-used parameters are passed in a struct rather than
as separate parameter-list entries. The objective here is to reduce the
probability that future additions to those parameter lists will result in
source-level API breaks for users of these hooks. It's possible that this
is even a small win for the core code, since most CPU architectures can't
pass more than half a dozen parameters efficiently anyway. I kept root,
joinrel, outerrel, innerrel, and jointype as separate parameters to reduce
code churn in joinpath.c --- in particular, putting jointype into the
struct would have been problematic because of the subroutines' habit of
changing their local copies of that variable.
* Avoid ad-hocery in ExecAssignScanProjectionInfo. It was probably all
right for it to know about IndexOnlyScan, but if the list is to grow
we should refactor the knowledge out to the callers.
* Restore nodeForeignscan.c's previous use of the relcache to avoid
extra GetFdwRoutine lookups for base-relation scans.
* Lots of cleanup of documentation and missed comments. Re-order some
code additions into more logical places.
10 years ago
|
|
|
|
|
|
|
|
/* Collect info about relation's foreign keys, if relevant */
|
|
|
|
|
get_relation_foreign_keys(root, rel, relation, inhparent);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Collect info about relation's partitioning scheme, if any. Only
|
|
|
|
|
* inheritance parents may be partitioned.
|
|
|
|
|
*/
|
|
|
|
|
if (inhparent && relation->rd_rel->relkind == RELKIND_PARTITIONED_TABLE)
|
|
|
|
|
set_relation_partition_info(root, rel, relation);
|
|
|
|
|
|
|
|
|
|
heap_close(relation, NoLock);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Allow a plugin to editorialize on the info we obtained from the
|
|
|
|
|
* catalogs. Actions might include altering the assumed relation size,
|
|
|
|
|
* removing an index, or adding a hypothetical index to the indexlist.
|
|
|
|
|
*/
|
|
|
|
|
if (get_relation_info_hook)
|
|
|
|
|
(*get_relation_info_hook) (root, relationObjectId, inhparent, rel);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* get_relation_foreign_keys -
|
|
|
|
|
* Retrieves foreign key information for a given relation.
|
|
|
|
|
*
|
|
|
|
|
* ForeignKeyOptInfos for relevant foreign keys are created and added to
|
|
|
|
|
* root->fkey_list. We do this now while we have the relcache entry open.
|
|
|
|
|
* We could sometimes avoid making useless ForeignKeyOptInfos if we waited
|
|
|
|
|
* until all RelOptInfos have been built, but the cost of re-opening the
|
|
|
|
|
* relcache entries would probably exceed any savings.
|
|
|
|
|
*/
|
|
|
|
|
static void
|
|
|
|
|
get_relation_foreign_keys(PlannerInfo *root, RelOptInfo *rel,
|
|
|
|
|
Relation relation, bool inhparent)
|
|
|
|
|
{
|
|
|
|
|
List *rtable = root->parse->rtable;
|
|
|
|
|
List *cachedfkeys;
|
|
|
|
|
ListCell *lc;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* If it's not a baserel, we don't care about its FKs. Also, if the query
|
|
|
|
|
* references only a single relation, we can skip the lookup since no FKs
|
|
|
|
|
* could satisfy the requirements below.
|
|
|
|
|
*/
|
|
|
|
|
if (rel->reloptkind != RELOPT_BASEREL ||
|
|
|
|
|
list_length(rtable) < 2)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* If it's the parent of an inheritance tree, ignore its FKs. We could
|
|
|
|
|
* make useful FK-based deductions if we found that all members of the
|
|
|
|
|
* inheritance tree have equivalent FK constraints, but detecting that
|
|
|
|
|
* would require code that hasn't been written.
|
|
|
|
|
*/
|
|
|
|
|
if (inhparent)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Extract data about relation's FKs from the relcache. Note that this
|
|
|
|
|
* list belongs to the relcache and might disappear in a cache flush, so
|
|
|
|
|
* we must not do any further catalog access within this function.
|
|
|
|
|
*/
|
|
|
|
|
cachedfkeys = RelationGetFKeyList(relation);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Figure out which FKs are of interest for this query, and create
|
|
|
|
|
* ForeignKeyOptInfos for them. We want only FKs that reference some
|
|
|
|
|
* other RTE of the current query. In queries containing self-joins,
|
|
|
|
|
* there might be more than one other RTE for a referenced table, and we
|
|
|
|
|
* should make a ForeignKeyOptInfo for each occurrence.
|
|
|
|
|
*
|
|
|
|
|
* Ideally, we would ignore RTEs that correspond to non-baserels, but it's
|
|
|
|
|
* too hard to identify those here, so we might end up making some useless
|
|
|
|
|
* ForeignKeyOptInfos. If so, match_foreign_keys_to_quals() will remove
|
|
|
|
|
* them again.
|
|
|
|
|
*/
|
|
|
|
|
foreach(lc, cachedfkeys)
|
|
|
|
|
{
|
|
|
|
|
ForeignKeyCacheInfo *cachedfk = (ForeignKeyCacheInfo *) lfirst(lc);
|
|
|
|
|
Index rti;
|
|
|
|
|
ListCell *lc2;
|
|
|
|
|
|
|
|
|
|
/* conrelid should always be that of the table we're considering */
|
|
|
|
|
Assert(cachedfk->conrelid == RelationGetRelid(relation));
|
|
|
|
|
|
|
|
|
|
/* Scan to find other RTEs matching confrelid */
|
|
|
|
|
rti = 0;
|
|
|
|
|
foreach(lc2, rtable)
|
|
|
|
|
{
|
|
|
|
|
RangeTblEntry *rte = (RangeTblEntry *) lfirst(lc2);
|
|
|
|
|
ForeignKeyOptInfo *info;
|
|
|
|
|
|
|
|
|
|
rti++;
|
|
|
|
|
/* Ignore if not the correct table */
|
|
|
|
|
if (rte->rtekind != RTE_RELATION ||
|
|
|
|
|
rte->relid != cachedfk->confrelid)
|
|
|
|
|
continue;
|
|
|
|
|
/* Ignore if it's an inheritance parent; doesn't really match */
|
|
|
|
|
if (rte->inh)
|
|
|
|
|
continue;
|
|
|
|
|
/* Ignore self-referential FKs; we only care about joins */
|
|
|
|
|
if (rti == rel->relid)
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
/* OK, let's make an entry */
|
|
|
|
|
info = makeNode(ForeignKeyOptInfo);
|
|
|
|
|
info->con_relid = rel->relid;
|
|
|
|
|
info->ref_relid = rti;
|
|
|
|
|
info->nkeys = cachedfk->nkeys;
|
|
|
|
|
memcpy(info->conkey, cachedfk->conkey, sizeof(info->conkey));
|
|
|
|
|
memcpy(info->confkey, cachedfk->confkey, sizeof(info->confkey));
|
|
|
|
|
memcpy(info->conpfeqop, cachedfk->conpfeqop, sizeof(info->conpfeqop));
|
|
|
|
|
/* zero out fields to be filled by match_foreign_keys_to_quals */
|
|
|
|
|
info->nmatched_ec = 0;
|
|
|
|
|
info->nmatched_rcols = 0;
|
|
|
|
|
info->nmatched_ri = 0;
|
|
|
|
|
memset(info->eclass, 0, sizeof(info->eclass));
|
|
|
|
|
memset(info->rinfos, 0, sizeof(info->rinfos));
|
|
|
|
|
|
|
|
|
|
root->fkey_list = lappend(root->fkey_list, info);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
10 years ago
|
|
|
/*
|
|
|
|
|
* infer_arbiter_indexes -
|
|
|
|
|
* Determine the unique indexes used to arbitrate speculative insertion.
|
|
|
|
|
*
|
|
|
|
|
* Uses user-supplied inference clause expressions and predicate to match a
|
|
|
|
|
* unique index from those defined and ready on the heap relation (target).
|
|
|
|
|
* An exact match is required on columns/expressions (although they can appear
|
|
|
|
|
* in any order). However, the predicate given by the user need only restrict
|
|
|
|
|
* insertion to a subset of some part of the table covered by some particular
|
|
|
|
|
* unique index (in particular, a partial unique index) in order to be
|
|
|
|
|
* inferred.
|
|
|
|
|
*
|
|
|
|
|
* The implementation does not consider which B-Tree operator class any
|
|
|
|
|
* particular available unique index attribute uses, unless one was specified
|
|
|
|
|
* in the inference specification. The same is true of collations. In
|
|
|
|
|
* particular, there is no system dependency on the default operator class for
|
|
|
|
|
* the purposes of inference. If no opclass (or collation) is specified, then
|
|
|
|
|
* all matching indexes (that may or may not match the default in terms of
|
|
|
|
|
* each attribute opclass/collation) are used for inference.
|
|
|
|
|
*/
|
|
|
|
|
List *
|
|
|
|
|
infer_arbiter_indexes(PlannerInfo *root)
|
|
|
|
|
{
|
|
|
|
|
OnConflictExpr *onconflict = root->parse->onConflict;
|
|
|
|
|
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
10 years ago
|
|
|
/* Iteration state */
|
|
|
|
|
Relation relation;
|
|
|
|
|
Oid relationObjectId;
|
|
|
|
|
Oid indexOidFromConstraint = InvalidOid;
|
|
|
|
|
List *indexList;
|
|
|
|
|
ListCell *l;
|
|
|
|
|
|
|
|
|
|
/* Normalized inference attributes and inference expressions: */
|
|
|
|
|
Bitmapset *inferAttrs = NULL;
|
|
|
|
|
List *inferElems = NIL;
|
|
|
|
|
|
|
|
|
|
/* Results */
|
|
|
|
|
List *results = NIL;
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
10 years ago
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Quickly return NIL for ON CONFLICT DO NOTHING without an inference
|
|
|
|
|
* specification or named constraint. ON CONFLICT DO UPDATE statements
|
|
|
|
|
* must always provide one or the other (but parser ought to have caught
|
|
|
|
|
* that already).
|
|
|
|
|
*/
|
|
|
|
|
if (onconflict->arbiterElems == NIL &&
|
|
|
|
|
onconflict->constraint == InvalidOid)
|
|
|
|
|
return NIL;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* We need not lock the relation since it was already locked, either by
|
|
|
|
|
* the rewriter or when expand_inherited_rtentry() added it to the query's
|
|
|
|
|
* rangetable.
|
|
|
|
|
*/
|
|
|
|
|
relationObjectId = rt_fetch(root->parse->resultRelation,
|
|
|
|
|
root->parse->rtable)->relid;
|
|
|
|
|
|
|
|
|
|
relation = heap_open(relationObjectId, NoLock);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Build normalized/BMS representation of plain indexed attributes, as
|
|
|
|
|
* well as a separate list of expression items. This simplifies matching
|
|
|
|
|
* the cataloged definition of indexes.
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
10 years ago
|
|
|
*/
|
|
|
|
|
foreach(l, onconflict->arbiterElems)
|
|
|
|
|
{
|
|
|
|
|
InferenceElem *elem = (InferenceElem *) lfirst(l);
|
|
|
|
|
Var *var;
|
|
|
|
|
int attno;
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
10 years ago
|
|
|
|
|
|
|
|
if (!IsA(elem->expr, Var))
|
|
|
|
|
{
|
|
|
|
|
/* If not a plain Var, just shove it in inferElems for now */
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
10 years ago
|
|
|
inferElems = lappend(inferElems, elem->expr);
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
var = (Var *) elem->expr;
|
|
|
|
|
attno = var->varattno;
|
|
|
|
|
|
|
|
|
|
if (attno == 0)
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
10 years ago
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
|
|
|
|
|
errmsg("whole row unique index inference specifications are not supported")));
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
10 years ago
|
|
|
|
|
|
|
|
inferAttrs = bms_add_member(inferAttrs,
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
8 years ago
|
|
|
attno - FirstLowInvalidHeapAttributeNumber);
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
10 years ago
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Lookup named constraint's index. This is not immediately returned
|
|
|
|
|
* because some additional sanity checks are required.
|
|
|
|
|
*/
|
|
|
|
|
if (onconflict->constraint != InvalidOid)
|
|
|
|
|
{
|
|
|
|
|
indexOidFromConstraint = get_constraint_index(onconflict->constraint);
|
|
|
|
|
|
|
|
|
|
if (indexOidFromConstraint == InvalidOid)
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
|
|
|
|
|
errmsg("constraint in ON CONFLICT clause has no associated index")));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Using that representation, iterate through the list of indexes on the
|
|
|
|
|
* target relation to try and find a match
|
|
|
|
|
*/
|
|
|
|
|
indexList = RelationGetIndexList(relation);
|
|
|
|
|
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
10 years ago
|
|
|
foreach(l, indexList)
|
|
|
|
|
{
|
|
|
|
|
Oid indexoid = lfirst_oid(l);
|
|
|
|
|
Relation idxRel;
|
|
|
|
|
Form_pg_index idxForm;
|
|
|
|
|
Bitmapset *indexedAttrs;
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
10 years ago
|
|
|
List *idxExprs;
|
|
|
|
|
List *predExprs;
|
|
|
|
|
AttrNumber natt;
|
|
|
|
|
ListCell *el;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Extract info from the relation descriptor for the index. We know
|
|
|
|
|
* that this is a target, so get lock type it is known will ultimately
|
|
|
|
|
* be required by the executor.
|
|
|
|
|
*
|
|
|
|
|
* Let executor complain about !indimmediate case directly, because
|
|
|
|
|
* enforcement needs to occur there anyway when an inference clause is
|
|
|
|
|
* omitted.
|
|
|
|
|
*/
|
|
|
|
|
idxRel = index_open(indexoid, RowExclusiveLock);
|
|
|
|
|
idxForm = idxRel->rd_index;
|
|
|
|
|
|
|
|
|
|
if (!IndexIsValid(idxForm))
|
|
|
|
|
goto next;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Note that we do not perform a check against indcheckxmin (like e.g.
|
|
|
|
|
* get_relation_info()) here to eliminate candidates, because
|
|
|
|
|
* uniqueness checking only cares about the most recently committed
|
|
|
|
|
* tuple versions.
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
10 years ago
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Look for match on "ON constraint_name" variant, which may not be
|
|
|
|
|
* unique constraint. This can only be a constraint name.
|
|
|
|
|
*/
|
|
|
|
|
if (indexOidFromConstraint == idxForm->indexrelid)
|
|
|
|
|
{
|
|
|
|
|
if (!idxForm->indisunique && onconflict->action == ONCONFLICT_UPDATE)
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
|
|
|
|
|
errmsg("ON CONFLICT DO UPDATE not supported with exclusion constraints")));
|
|
|
|
|
|
|
|
|
|
results = lappend_oid(results, idxForm->indexrelid);
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
10 years ago
|
|
|
list_free(indexList);
|
|
|
|
|
index_close(idxRel, NoLock);
|
|
|
|
|
heap_close(relation, NoLock);
|
|
|
|
|
return results;
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
10 years ago
|
|
|
}
|
|
|
|
|
else if (indexOidFromConstraint != InvalidOid)
|
|
|
|
|
{
|
|
|
|
|
/* No point in further work for index in named constraint case */
|
|
|
|
|
goto next;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Only considering conventional inference at this point (not named
|
|
|
|
|
* constraints), so index under consideration can be immediately
|
|
|
|
|
* skipped if it's not unique
|
|
|
|
|
*/
|
|
|
|
|
if (!idxForm->indisunique)
|
|
|
|
|
goto next;
|
|
|
|
|
|
|
|
|
|
/* Build BMS representation of plain (non expression) index attrs */
|
|
|
|
|
indexedAttrs = NULL;
|
|
|
|
|
for (natt = 0; natt < idxForm->indnkeyatts; natt++)
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
10 years ago
|
|
|
{
|
|
|
|
|
int attno = idxRel->rd_index->indkey.values[natt];
|
|
|
|
|
|
|
|
|
|
if (attno != 0)
|
|
|
|
|
indexedAttrs = bms_add_member(indexedAttrs,
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
8 years ago
|
|
|
attno - FirstLowInvalidHeapAttributeNumber);
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
10 years ago
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Non-expression attributes (if any) must match */
|
|
|
|
|
if (!bms_equal(indexedAttrs, inferAttrs))
|
|
|
|
|
goto next;
|
|
|
|
|
|
|
|
|
|
/* Expression attributes (if any) must match */
|
|
|
|
|
idxExprs = RelationGetIndexExpressions(idxRel);
|
|
|
|
|
foreach(el, onconflict->arbiterElems)
|
|
|
|
|
{
|
|
|
|
|
InferenceElem *elem = (InferenceElem *) lfirst(el);
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
10 years ago
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Ensure that collation/opclass aspects of inference expression
|
|
|
|
|
* element match. Even though this loop is primarily concerned
|
|
|
|
|
* with matching expressions, it is a convenient point to check
|
|
|
|
|
* this for both expressions and ordinary (non-expression)
|
|
|
|
|
* attributes appearing as inference elements.
|
|
|
|
|
*/
|
|
|
|
|
if (!infer_collation_opclass_match(elem, idxRel, idxExprs))
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
10 years ago
|
|
|
goto next;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Plain Vars don't factor into count of expression elements, and
|
|
|
|
|
* the question of whether or not they satisfy the index
|
|
|
|
|
* definition has already been considered (they must).
|
|
|
|
|
*/
|
|
|
|
|
if (IsA(elem->expr, Var))
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Might as well avoid redundant check in the rare cases where
|
|
|
|
|
* infer_collation_opclass_match() is required to do real work.
|
|
|
|
|
* Otherwise, check that element expression appears in cataloged
|
|
|
|
|
* index definition.
|
|
|
|
|
*/
|
|
|
|
|
if (elem->infercollid != InvalidOid ||
|
|
|
|
|
elem->inferopclass != InvalidOid ||
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
10 years ago
|
|
|
list_member(idxExprs, elem->expr))
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
goto next;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Now that all inference elements were matched, ensure that the
|
|
|
|
|
* expression elements from inference clause are not missing any
|
|
|
|
|
* cataloged expressions. This does the right thing when unique
|
|
|
|
|
* indexes redundantly repeat the same attribute, or if attributes
|
|
|
|
|
* redundantly appear multiple times within an inference clause.
|
|
|
|
|
*/
|
|
|
|
|
if (list_difference(idxExprs, inferElems) != NIL)
|
|
|
|
|
goto next;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* If it's a partial index, its predicate must be implied by the ON
|
|
|
|
|
* CONFLICT's WHERE clause.
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
10 years ago
|
|
|
*/
|
|
|
|
|
predExprs = RelationGetIndexPredicate(idxRel);
|
|
|
|
|
|
|
|
|
|
if (!predicate_implied_by(predExprs, (List *) onconflict->arbiterWhere, false))
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
10 years ago
|
|
|
goto next;
|
|
|
|
|
|
|
|
|
|
results = lappend_oid(results, idxForm->indexrelid);
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
10 years ago
|
|
|
next:
|
|
|
|
|
index_close(idxRel, NoLock);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
list_free(indexList);
|
|
|
|
|
heap_close(relation, NoLock);
|
|
|
|
|
|
|
|
|
|
if (results == NIL)
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
10 years ago
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_INVALID_COLUMN_REFERENCE),
|
|
|
|
|
errmsg("there is no unique or exclusion constraint matching the ON CONFLICT specification")));
|
|
|
|
|
|
|
|
|
|
return results;
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
10 years ago
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* infer_collation_opclass_match - ensure infer element opclass/collation match
|
|
|
|
|
*
|
|
|
|
|
* Given unique index inference element from inference specification, if
|
|
|
|
|
* collation was specified, or if opclass was specified, verify that there is
|
|
|
|
|
* at least one matching indexed attribute (occasionally, there may be more).
|
|
|
|
|
* Skip this in the common case where inference specification does not include
|
|
|
|
|
* collation or opclass (instead matching everything, regardless of cataloged
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
10 years ago
|
|
|
* collation/opclass of indexed attribute).
|
|
|
|
|
*
|
|
|
|
|
* At least historically, Postgres has not offered collations or opclasses
|
|
|
|
|
* with alternative-to-default notions of equality, so these additional
|
|
|
|
|
* criteria should only be required infrequently.
|
|
|
|
|
*
|
|
|
|
|
* Don't give up immediately when an inference element matches some attribute
|
|
|
|
|
* cataloged as indexed but not matching additional opclass/collation
|
|
|
|
|
* criteria. This is done so that the implementation is as forgiving as
|
|
|
|
|
* possible of redundancy within cataloged index attributes (or, less
|
|
|
|
|
* usefully, within inference specification elements). If collations actually
|
|
|
|
|
* differ between apparently redundantly indexed attributes (redundant within
|
|
|
|
|
* or across indexes), then there really is no redundancy as such.
|
|
|
|
|
*
|
|
|
|
|
* Note that if an inference element specifies an opclass and a collation at
|
|
|
|
|
* once, both must match in at least one particular attribute within index
|
|
|
|
|
* catalog definition in order for that inference element to be considered
|
|
|
|
|
* inferred/satisfied.
|
|
|
|
|
*/
|
|
|
|
|
static bool
|
|
|
|
|
infer_collation_opclass_match(InferenceElem *elem, Relation idxRel,
|
|
|
|
|
List *idxExprs)
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
10 years ago
|
|
|
{
|
|
|
|
|
AttrNumber natt;
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
8 years ago
|
|
|
Oid inferopfamily = InvalidOid; /* OID of opclass opfamily */
|
|
|
|
|
Oid inferopcinputtype = InvalidOid; /* OID of opclass input type */
|
|
|
|
|
int nplain = 0; /* # plain attrs observed */
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
10 years ago
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* If inference specification element lacks collation/opclass, then no
|
|
|
|
|
* need to check for exact match.
|
|
|
|
|
*/
|
|
|
|
|
if (elem->infercollid == InvalidOid && elem->inferopclass == InvalidOid)
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
10 years ago
|
|
|
return true;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Lookup opfamily and input type, for matching indexes
|
|
|
|
|
*/
|
|
|
|
|
if (elem->inferopclass)
|
|
|
|
|
{
|
|
|
|
|
inferopfamily = get_opclass_family(elem->inferopclass);
|
|
|
|
|
inferopcinputtype = get_opclass_input_type(elem->inferopclass);
|
|
|
|
|
}
|
|
|
|
|
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
10 years ago
|
|
|
for (natt = 1; natt <= idxRel->rd_att->natts; natt++)
|
|
|
|
|
{
|
|
|
|
|
Oid opfamily = idxRel->rd_opfamily[natt - 1];
|
|
|
|
|
Oid opcinputtype = idxRel->rd_opcintype[natt - 1];
|
|
|
|
|
Oid collation = idxRel->rd_indcollation[natt - 1];
|
|
|
|
|
int attno = idxRel->rd_index->indkey.values[natt - 1];
|
|
|
|
|
|
|
|
|
|
if (attno != 0)
|
|
|
|
|
nplain++;
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
10 years ago
|
|
|
|
|
|
|
|
if (elem->inferopclass != InvalidOid &&
|
|
|
|
|
(inferopfamily != opfamily || inferopcinputtype != opcinputtype))
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
10 years ago
|
|
|
{
|
|
|
|
|
/* Attribute needed to match opclass, but didn't */
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (elem->infercollid != InvalidOid &&
|
|
|
|
|
elem->infercollid != collation)
|
|
|
|
|
{
|
|
|
|
|
/* Attribute needed to match collation, but didn't */
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* If one matching index att found, good enough -- return true */
|
|
|
|
|
if (IsA(elem->expr, Var))
|
|
|
|
|
{
|
|
|
|
|
if (((Var *) elem->expr)->varattno == attno)
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
else if (attno == 0)
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
10 years ago
|
|
|
{
|
|
|
|
|
Node *nattExpr = list_nth(idxExprs, (natt - 1) - nplain);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Note that unlike routines like match_index_to_operand() we
|
|
|
|
|
* don't need to care about RelabelType. Neither the index
|
|
|
|
|
* definition nor the inference clause should contain them.
|
|
|
|
|
*/
|
|
|
|
|
if (equal(elem->expr, nattExpr))
|
|
|
|
|
return true;
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
10 years ago
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* estimate_rel_size - estimate # pages and # tuples in a table or index
|
|
|
|
|
*
|
|
|
|
|
* We also estimate the fraction of the pages that are marked all-visible in
|
|
|
|
|
* the visibility map, for use in estimation of index-only scans.
|
|
|
|
|
*
|
|
|
|
|
* If attr_widths isn't NULL, it points to the zero-index entry of the
|
|
|
|
|
* relation's attr_widths[] cache; we fill this in if we have need to compute
|
|
|
|
|
* the attribute widths for estimation purposes.
|
|
|
|
|
*/
|
|
|
|
|
void
|
|
|
|
|
estimate_rel_size(Relation rel, int32 *attr_widths,
|
|
|
|
|
BlockNumber *pages, double *tuples, double *allvisfrac)
|
|
|
|
|
{
|
|
|
|
|
BlockNumber curpages;
|
|
|
|
|
BlockNumber relpages;
|
|
|
|
|
double reltuples;
|
|
|
|
|
BlockNumber relallvisible;
|
|
|
|
|
double density;
|
|
|
|
|
|
|
|
|
|
switch (rel->rd_rel->relkind)
|
|
|
|
|
{
|
|
|
|
|
case RELKIND_RELATION:
|
|
|
|
|
case RELKIND_INDEX:
|
|
|
|
|
case RELKIND_MATVIEW:
|
|
|
|
|
case RELKIND_TOASTVALUE:
|
|
|
|
|
/* it has storage, ok to call the smgr */
|
|
|
|
|
curpages = RelationGetNumberOfBlocks(rel);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* HACK: if the relation has never yet been vacuumed, use a
|
|
|
|
|
* minimum size estimate of 10 pages. The idea here is to avoid
|
|
|
|
|
* assuming a newly-created table is really small, even if it
|
|
|
|
|
* currently is, because that may not be true once some data gets
|
|
|
|
|
* loaded into it. Once a vacuum or analyze cycle has been done
|
|
|
|
|
* on it, it's more reasonable to believe the size is somewhat
|
|
|
|
|
* stable.
|
|
|
|
|
*
|
|
|
|
|
* (Note that this is only an issue if the plan gets cached and
|
|
|
|
|
* used again after the table has been filled. What we're trying
|
|
|
|
|
* to avoid is using a nestloop-type plan on a table that has
|
|
|
|
|
* grown substantially since the plan was made. Normally,
|
|
|
|
|
* autovacuum/autoanalyze will occur once enough inserts have
|
|
|
|
|
* happened and cause cached-plan invalidation; but that doesn't
|
|
|
|
|
* happen instantaneously, and it won't happen at all for cases
|
|
|
|
|
* such as temporary tables.)
|
|
|
|
|
*
|
|
|
|
|
* We approximate "never vacuumed" by "has relpages = 0", which
|
|
|
|
|
* means this will also fire on genuinely empty relations. Not
|
|
|
|
|
* great, but fortunately that's a seldom-seen case in the real
|
|
|
|
|
* world, and it shouldn't degrade the quality of the plan too
|
|
|
|
|
* much anyway to err in this direction.
|
|
|
|
|
*
|
|
|
|
|
* There are two exceptions wherein we don't apply this heuristic.
|
|
|
|
|
* One is if the table has inheritance children. Totally empty
|
|
|
|
|
* parent tables are quite common, so we should be willing to
|
|
|
|
|
* believe that they are empty. Also, we don't apply the 10-page
|
|
|
|
|
* minimum to indexes.
|
|
|
|
|
*/
|
|
|
|
|
if (curpages < 10 &&
|
|
|
|
|
rel->rd_rel->relpages == 0 &&
|
|
|
|
|
!rel->rd_rel->relhassubclass &&
|
|
|
|
|
rel->rd_rel->relkind != RELKIND_INDEX)
|
|
|
|
|
curpages = 10;
|
|
|
|
|
|
|
|
|
|
/* report estimated # pages */
|
|
|
|
|
*pages = curpages;
|
|
|
|
|
/* quick exit if rel is clearly empty */
|
|
|
|
|
if (curpages == 0)
|
|
|
|
|
{
|
|
|
|
|
*tuples = 0;
|
|
|
|
|
*allvisfrac = 0;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
/* coerce values in pg_class to more desirable types */
|
|
|
|
|
relpages = (BlockNumber) rel->rd_rel->relpages;
|
|
|
|
|
reltuples = (double) rel->rd_rel->reltuples;
|
|
|
|
|
relallvisible = (BlockNumber) rel->rd_rel->relallvisible;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* If it's an index, discount the metapage while estimating the
|
|
|
|
|
* number of tuples. This is a kluge because it assumes more than
|
|
|
|
|
* it ought to about index structure. Currently it's OK for
|
|
|
|
|
* btree, hash, and GIN indexes but suspect for GiST indexes.
|
|
|
|
|
*/
|
|
|
|
|
if (rel->rd_rel->relkind == RELKIND_INDEX &&
|
|
|
|
|
relpages > 0)
|
|
|
|
|
{
|
|
|
|
|
curpages--;
|
|
|
|
|
relpages--;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* estimate number of tuples from previous tuple density */
|
|
|
|
|
if (relpages > 0)
|
|
|
|
|
density = reltuples / (double) relpages;
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
/*
|
|
|
|
|
* When we have no data because the relation was truncated,
|
|
|
|
|
* estimate tuple width from attribute datatypes. We assume
|
|
|
|
|
* here that the pages are completely full, which is OK for
|
|
|
|
|
* tables (since they've presumably not been VACUUMed yet) but
|
|
|
|
|
* is probably an overestimate for indexes. Fortunately
|
|
|
|
|
* get_relation_info() can clamp the overestimate to the
|
|
|
|
|
* parent table's size.
|
|
|
|
|
*
|
|
|
|
|
* Note: this code intentionally disregards alignment
|
|
|
|
|
* considerations, because (a) that would be gilding the lily
|
|
|
|
|
* considering how crude the estimate is, and (b) it creates
|
|
|
|
|
* platform dependencies in the default plans which are kind
|
|
|
|
|
* of a headache for regression testing.
|
|
|
|
|
*/
|
|
|
|
|
int32 tuple_width;
|
|
|
|
|
|
|
|
|
|
tuple_width = get_rel_data_width(rel, attr_widths);
|
|
|
|
|
tuple_width += MAXALIGN(SizeofHeapTupleHeader);
|
|
|
|
|
tuple_width += sizeof(ItemIdData);
|
|
|
|
|
/* note: integer division is intentional here */
|
|
|
|
|
density = (BLCKSZ - SizeOfPageHeaderData) / tuple_width;
|
|
|
|
|
}
|
|
|
|
|
*tuples = rint(density * (double) curpages);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* We use relallvisible as-is, rather than scaling it up like we
|
|
|
|
|
* do for the pages and tuples counts, on the theory that any
|
|
|
|
|
* pages added since the last VACUUM are most likely not marked
|
|
|
|
|
* all-visible. But costsize.c wants it converted to a fraction.
|
|
|
|
|
*/
|
|
|
|
|
if (relallvisible == 0 || curpages <= 0)
|
|
|
|
|
*allvisfrac = 0;
|
|
|
|
|
else if ((double) relallvisible >= curpages)
|
|
|
|
|
*allvisfrac = 1;
|
|
|
|
|
else
|
|
|
|
|
*allvisfrac = (double) relallvisible / curpages;
|
|
|
|
|
break;
|
|
|
|
|
case RELKIND_SEQUENCE:
|
|
|
|
|
/* Sequences always have a known size */
|
|
|
|
|
*pages = 1;
|
|
|
|
|
*tuples = 1;
|
|
|
|
|
*allvisfrac = 0;
|
|
|
|
|
break;
|
|
|
|
|
case RELKIND_FOREIGN_TABLE:
|
|
|
|
|
/* Just use whatever's in pg_class */
|
|
|
|
|
*pages = rel->rd_rel->relpages;
|
|
|
|
|
*tuples = rel->rd_rel->reltuples;
|
|
|
|
|
*allvisfrac = 0;
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
/* else it has no disk storage; probably shouldn't get here? */
|
|
|
|
|
*pages = 0;
|
|
|
|
|
*tuples = 0;
|
|
|
|
|
*allvisfrac = 0;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* get_rel_data_width
|
|
|
|
|
*
|
|
|
|
|
* Estimate the average width of (the data part of) the relation's tuples.
|
|
|
|
|
*
|
|
|
|
|
* If attr_widths isn't NULL, it points to the zero-index entry of the
|
|
|
|
|
* relation's attr_widths[] cache; use and update that cache as appropriate.
|
|
|
|
|
*
|
|
|
|
|
* Currently we ignore dropped columns. Ideally those should be included
|
|
|
|
|
* in the result, but we haven't got any way to get info about them; and
|
|
|
|
|
* since they might be mostly NULLs, treating them as zero-width is not
|
|
|
|
|
* necessarily the wrong thing anyway.
|
|
|
|
|
*/
|
|
|
|
|
static int32
|
|
|
|
|
get_rel_data_width(Relation rel, int32 *attr_widths)
|
|
|
|
|
{
|
|
|
|
|
int32 tuple_width = 0;
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
for (i = 1; i <= RelationGetNumberOfAttributes(rel); i++)
|
|
|
|
|
{
|
|
|
|
|
Form_pg_attribute att = TupleDescAttr(rel->rd_att, i - 1);
|
|
|
|
|
int32 item_width;
|
|
|
|
|
|
|
|
|
|
if (att->attisdropped)
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
/* use previously cached data, if any */
|
|
|
|
|
if (attr_widths != NULL && attr_widths[i] > 0)
|
|
|
|
|
{
|
|
|
|
|
tuple_width += attr_widths[i];
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* This should match set_rel_width() in costsize.c */
|
|
|
|
|
item_width = get_attavgwidth(RelationGetRelid(rel), i);
|
|
|
|
|
if (item_width <= 0)
|
|
|
|
|
{
|
|
|
|
|
item_width = get_typavgwidth(att->atttypid, att->atttypmod);
|
|
|
|
|
Assert(item_width > 0);
|
|
|
|
|
}
|
|
|
|
|
if (attr_widths != NULL)
|
|
|
|
|
attr_widths[i] = item_width;
|
|
|
|
|
tuple_width += item_width;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return tuple_width;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* get_relation_data_width
|
|
|
|
|
*
|
|
|
|
|
* External API for get_rel_data_width: same behavior except we have to
|
|
|
|
|
* open the relcache entry.
|
|
|
|
|
*/
|
|
|
|
|
int32
|
|
|
|
|
get_relation_data_width(Oid relid, int32 *attr_widths)
|
|
|
|
|
{
|
|
|
|
|
int32 result;
|
|
|
|
|
Relation relation;
|
|
|
|
|
|
|
|
|
|
/* As above, assume relation is already locked */
|
|
|
|
|
relation = heap_open(relid, NoLock);
|
|
|
|
|
|
|
|
|
|
result = get_rel_data_width(relation, attr_widths);
|
|
|
|
|
|
|
|
|
|
heap_close(relation, NoLock);
|
|
|
|
|
|
|
|
|
|
return result;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* get_relation_constraints
|
|
|
|
|
*
|
|
|
|
|
* Retrieve the validated CHECK constraint expressions of the given relation.
|
|
|
|
|
*
|
|
|
|
|
* Returns a List (possibly empty) of constraint expressions. Each one
|
|
|
|
|
* has been canonicalized, and its Vars are changed to have the varno
|
|
|
|
|
* indicated by rel->relid. This allows the expressions to be easily
|
|
|
|
|
* compared to expressions taken from WHERE.
|
|
|
|
|
*
|
|
|
|
|
* If include_notnull is true, "col IS NOT NULL" expressions are generated
|
|
|
|
|
* and added to the result for each column that's marked attnotnull.
|
|
|
|
|
*
|
|
|
|
|
* Note: at present this is invoked at most once per relation per planner
|
|
|
|
|
* run, and in many cases it won't be invoked at all, so there seems no
|
|
|
|
|
* point in caching the data in RelOptInfo.
|
|
|
|
|
*/
|
|
|
|
|
static List *
|
|
|
|
|
get_relation_constraints(PlannerInfo *root,
|
|
|
|
|
Oid relationObjectId, RelOptInfo *rel,
|
|
|
|
|
bool include_notnull)
|
|
|
|
|
{
|
|
|
|
|
List *result = NIL;
|
|
|
|
|
Index varno = rel->relid;
|
|
|
|
|
Relation relation;
|
|
|
|
|
TupleConstr *constr;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* We assume the relation has already been safely locked.
|
|
|
|
|
*/
|
|
|
|
|
relation = heap_open(relationObjectId, NoLock);
|
|
|
|
|
|
|
|
|
|
constr = relation->rd_att->constr;
|
|
|
|
|
if (constr != NULL)
|
|
|
|
|
{
|
|
|
|
|
int num_check = constr->num_check;
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < num_check; i++)
|
|
|
|
|
{
|
|
|
|
|
Node *cexpr;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* If this constraint hasn't been fully validated yet, we must
|
|
|
|
|
* ignore it here.
|
|
|
|
|
*/
|
|
|
|
|
if (!constr->check[i].ccvalid)
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
cexpr = stringToNode(constr->check[i].ccbin);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Run each expression through const-simplification and
|
|
|
|
|
* canonicalization. This is not just an optimization, but is
|
|
|
|
|
* necessary, because we will be comparing it to
|
|
|
|
|
* similarly-processed qual clauses, and may fail to detect valid
|
|
|
|
|
* matches without this. This must match the processing done to
|
|
|
|
|
* qual clauses in preprocess_expression()! (We can skip the
|
|
|
|
|
* stuff involving subqueries, however, since we don't allow any
|
|
|
|
|
* in check constraints.)
|
|
|
|
|
*/
|
|
|
|
|
cexpr = eval_const_expressions(root, cexpr);
|
|
|
|
|
|
Fix improper uses of canonicalize_qual().
One of the things canonicalize_qual() does is to remove constant-NULL
subexpressions of top-level AND/OR clauses. It does that on the assumption
that what it's given is a top-level WHERE clause, so that NULL can be
treated like FALSE. Although this is documented down inside a subroutine
of canonicalize_qual(), it wasn't mentioned in the documentation of that
function itself, and some callers hadn't gotten that memo.
Notably, commit d007a9505 caused get_relation_constraints() to apply
canonicalize_qual() to CHECK constraints. That allowed constraint
exclusion to misoptimize situations in which a CHECK constraint had a
provably-NULL subclause, as seen in the regression test case added here,
in which a child table that should be scanned is not. (Although this
thinko is ancient, the test case doesn't fail before 9.2, for reasons
I've not bothered to track down in detail. There may be related cases
that do fail before that.)
More recently, commit f0e44751d added an independent bug by applying
canonicalize_qual() to index expressions, which is even sillier since
those might not even be boolean. If they are, though, I think this
could lead to making incorrect index entries for affected index
expressions in v10. I haven't attempted to prove that though.
To fix, add an "is_check" parameter to canonicalize_qual() to specify
whether it should assume WHERE or CHECK semantics, and make it perform
NULL-elimination accordingly. Adjust the callers to apply the right
semantics, or remove the call entirely in cases where it's not known
that the expression has one or the other semantics. I also removed
the call in some cases involving partition expressions, where it should
be a no-op because such expressions should be canonical already ...
and was a no-op, independently of whether it could in principle have
done something, because it was being handed the qual in implicit-AND
format which isn't what it expects. In HEAD, add an Assert to catch
that type of mistake in future.
This represents an API break for external callers of canonicalize_qual().
While that's intentional in HEAD to make such callers think about which
case applies to them, it seems like something we probably wouldn't be
thanked for in released branches. Hence, in released branches, the
extra parameter is added to a new function canonicalize_qual_ext(),
and canonicalize_qual() is a wrapper that retains its old behavior.
Patch by me with suggestions from Dean Rasheed. Back-patch to all
supported branches.
Discussion: https://postgr.es/m/24475.1520635069@sss.pgh.pa.us
7 years ago
|
|
|
cexpr = (Node *) canonicalize_qual((Expr *) cexpr, true);
|
|
|
|
|
|
|
|
|
|
/* Fix Vars to have the desired varno */
|
|
|
|
|
if (varno != 1)
|
|
|
|
|
ChangeVarNodes(cexpr, 1, varno, 0);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Finally, convert to implicit-AND format (that is, a List) and
|
|
|
|
|
* append the resulting item(s) to our output list.
|
|
|
|
|
*/
|
|
|
|
|
result = list_concat(result,
|
|
|
|
|
make_ands_implicit((Expr *) cexpr));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Add NOT NULL constraints in expression form, if requested */
|
|
|
|
|
if (include_notnull && constr->has_not_null)
|
|
|
|
|
{
|
|
|
|
|
int natts = relation->rd_att->natts;
|
|
|
|
|
|
|
|
|
|
for (i = 1; i <= natts; i++)
|
|
|
|
|
{
|
|
|
|
|
Form_pg_attribute att = TupleDescAttr(relation->rd_att, i - 1);
|
|
|
|
|
|
|
|
|
|
if (att->attnotnull && !att->attisdropped)
|
|
|
|
|
{
|
|
|
|
|
NullTest *ntest = makeNode(NullTest);
|
|
|
|
|
|
|
|
|
|
ntest->arg = (Expr *) makeVar(varno,
|
|
|
|
|
i,
|
|
|
|
|
att->atttypid,
|
|
|
|
|
att->atttypmod,
|
|
|
|
|
att->attcollation,
|
|
|
|
|
0);
|
|
|
|
|
ntest->nulltesttype = IS_NOT_NULL;
|
Fix assorted fallout from IS [NOT] NULL patch.
Commits 4452000f3 et al established semantics for NullTest.argisrow that
are a bit different from its initial conception: rather than being merely
a cache of whether we've determined the input to have composite type,
the flag now has the further meaning that we should apply field-by-field
testing as per the standard's definition of IS [NOT] NULL. If argisrow
is false and yet the input has composite type, the construct instead has
the semantics of IS [NOT] DISTINCT FROM NULL. Update the comments in
primnodes.h to clarify this, and fix ruleutils.c and deparse.c to print
such cases correctly. In the case of ruleutils.c, this merely results in
cosmetic changes in EXPLAIN output, since the case can't currently arise
in stored rules. However, it represents a live bug for deparse.c, which
would formerly have sent a remote query that had semantics different
from the local behavior. (From the user's standpoint, this means that
testing a remote nested-composite column for null-ness could have had
unexpected recursive behavior much like that fixed in 4452000f3.)
In a related but somewhat independent fix, make plancat.c set argisrow
to false in all NullTest expressions constructed to represent "attnotnull"
constructs. Since attnotnull is actually enforced as a simple null-value
check, this is a more accurate representation of the semantics; we were
previously overpromising what it meant for composite columns, which might
possibly lead to incorrect planner optimizations. (It seems that what the
SQL spec expects a NOT NULL constraint to mean is an IS NOT NULL test, so
arguably we are violating the spec and should fix attnotnull to do the
other thing. If we ever do, this part should get reverted.)
Back-patch, same as the previous commit.
Discussion: <10682.1469566308@sss.pgh.pa.us>
9 years ago
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* argisrow=false is correct even for a composite column,
|
|
|
|
|
* because attnotnull does not represent a SQL-spec IS NOT
|
|
|
|
|
* NULL test in such a case, just IS DISTINCT FROM NULL.
|
|
|
|
|
*/
|
|
|
|
|
ntest->argisrow = false;
|
|
|
|
|
ntest->location = -1;
|
|
|
|
|
result = lappend(result, ntest);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
Faster partition pruning
Add a new module backend/partitioning/partprune.c, implementing a more
sophisticated algorithm for partition pruning. The new module uses each
partition's "boundinfo" for pruning instead of constraint exclusion,
based on an idea proposed by Robert Haas of a "pruning program": a list
of steps generated from the query quals which are run iteratively to
obtain a list of partitions that must be scanned in order to satisfy
those quals.
At present, this targets planner-time partition pruning, but there exist
further patches to apply partition pruning at execution time as well.
This commit also moves some definitions from include/catalog/partition.h
to a new file include/partitioning/partbounds.h, in an attempt to
rationalize partitioning related code.
Authors: Amit Langote, David Rowley, Dilip Kumar
Reviewers: Robert Haas, Kyotaro Horiguchi, Ashutosh Bapat, Jesper Pedersen.
Discussion: https://postgr.es/m/098b9c71-1915-1a2a-8d52-1a7a50ce79e8@lab.ntt.co.jp
7 years ago
|
|
|
/*
|
|
|
|
|
* Append partition predicates, if any.
|
|
|
|
|
*
|
|
|
|
|
* For selects, partition pruning uses the parent table's partition bound
|
|
|
|
|
* descriptor, instead of constraint exclusion which is driven by the
|
|
|
|
|
* individual partition's partition constraint.
|
|
|
|
|
*/
|
|
|
|
|
if (enable_partition_pruning && root->parse->commandType != CMD_SELECT)
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
9 years ago
|
|
|
{
|
Faster partition pruning
Add a new module backend/partitioning/partprune.c, implementing a more
sophisticated algorithm for partition pruning. The new module uses each
partition's "boundinfo" for pruning instead of constraint exclusion,
based on an idea proposed by Robert Haas of a "pruning program": a list
of steps generated from the query quals which are run iteratively to
obtain a list of partitions that must be scanned in order to satisfy
those quals.
At present, this targets planner-time partition pruning, but there exist
further patches to apply partition pruning at execution time as well.
This commit also moves some definitions from include/catalog/partition.h
to a new file include/partitioning/partbounds.h, in an attempt to
rationalize partitioning related code.
Authors: Amit Langote, David Rowley, Dilip Kumar
Reviewers: Robert Haas, Kyotaro Horiguchi, Ashutosh Bapat, Jesper Pedersen.
Discussion: https://postgr.es/m/098b9c71-1915-1a2a-8d52-1a7a50ce79e8@lab.ntt.co.jp
7 years ago
|
|
|
List *pcqual = RelationGetPartitionQual(relation);
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
9 years ago
|
|
|
|
Faster partition pruning
Add a new module backend/partitioning/partprune.c, implementing a more
sophisticated algorithm for partition pruning. The new module uses each
partition's "boundinfo" for pruning instead of constraint exclusion,
based on an idea proposed by Robert Haas of a "pruning program": a list
of steps generated from the query quals which are run iteratively to
obtain a list of partitions that must be scanned in order to satisfy
those quals.
At present, this targets planner-time partition pruning, but there exist
further patches to apply partition pruning at execution time as well.
This commit also moves some definitions from include/catalog/partition.h
to a new file include/partitioning/partbounds.h, in an attempt to
rationalize partitioning related code.
Authors: Amit Langote, David Rowley, Dilip Kumar
Reviewers: Robert Haas, Kyotaro Horiguchi, Ashutosh Bapat, Jesper Pedersen.
Discussion: https://postgr.es/m/098b9c71-1915-1a2a-8d52-1a7a50ce79e8@lab.ntt.co.jp
7 years ago
|
|
|
if (pcqual)
|
|
|
|
|
{
|
|
|
|
|
/*
|
|
|
|
|
* Run the partition quals through const-simplification similar to
|
|
|
|
|
* check constraints. We skip canonicalize_qual, though, because
|
|
|
|
|
* partition quals should be in canonical form already; also,
|
|
|
|
|
* since the qual is in implicit-AND format, we'd have to
|
|
|
|
|
* explicitly convert it to explicit-AND format and back again.
|
|
|
|
|
*/
|
|
|
|
|
pcqual = (List *) eval_const_expressions(root, (Node *) pcqual);
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
9 years ago
|
|
|
|
Faster partition pruning
Add a new module backend/partitioning/partprune.c, implementing a more
sophisticated algorithm for partition pruning. The new module uses each
partition's "boundinfo" for pruning instead of constraint exclusion,
based on an idea proposed by Robert Haas of a "pruning program": a list
of steps generated from the query quals which are run iteratively to
obtain a list of partitions that must be scanned in order to satisfy
those quals.
At present, this targets planner-time partition pruning, but there exist
further patches to apply partition pruning at execution time as well.
This commit also moves some definitions from include/catalog/partition.h
to a new file include/partitioning/partbounds.h, in an attempt to
rationalize partitioning related code.
Authors: Amit Langote, David Rowley, Dilip Kumar
Reviewers: Robert Haas, Kyotaro Horiguchi, Ashutosh Bapat, Jesper Pedersen.
Discussion: https://postgr.es/m/098b9c71-1915-1a2a-8d52-1a7a50ce79e8@lab.ntt.co.jp
7 years ago
|
|
|
/* Fix Vars to have the desired varno */
|
|
|
|
|
if (varno != 1)
|
|
|
|
|
ChangeVarNodes((Node *) pcqual, 1, varno, 0);
|
|
|
|
|
|
|
|
|
|
result = list_concat(result, pcqual);
|
|
|
|
|
}
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
9 years ago
|
|
|
}
|
|
|
|
|
|
|
|
|
|
heap_close(relation, NoLock);
|
|
|
|
|
|
|
|
|
|
return result;
|
|
|
|
|
}
|
|
|
|
|
|
Implement multivariate n-distinct coefficients
Add support for explicitly declared statistic objects (CREATE
STATISTICS), allowing collection of statistics on more complex
combinations that individual table columns. Companion commands DROP
STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are
added too. All this DDL has been designed so that more statistic types
can be added later on, such as multivariate most-common-values and
multivariate histograms between columns of a single table, leaving room
for permitting columns on multiple tables, too, as well as expressions.
This commit only adds support for collection of n-distinct coefficient
on user-specified sets of columns in a single table. This is useful to
estimate number of distinct groups in GROUP BY and DISTINCT clauses;
estimation errors there can cause over-allocation of memory in hashed
aggregates, for instance, so it's a worthwhile problem to solve. A new
special pseudo-type pg_ndistinct is used.
(num-distinct estimation was deemed sufficiently useful by itself that
this is worthwhile even if no further statistic types are added
immediately; so much so that another version of essentially the same
functionality was submitted by Kyotaro Horiguchi:
https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp
though this commit does not use that code.)
Author: Tomas Vondra. Some code rework by Álvaro.
Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes,
Ideriha Takeshi
Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz
https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
8 years ago
|
|
|
/*
|
|
|
|
|
* get_relation_statistics
|
|
|
|
|
* Retrieve extended statistics defined on the table.
|
|
|
|
|
*
|
|
|
|
|
* Returns a List (possibly empty) of StatisticExtInfo objects describing
|
|
|
|
|
* the statistics. Note that this doesn't load the actual statistics data,
|
|
|
|
|
* just the identifying metadata. Only stats actually built are considered.
|
|
|
|
|
*/
|
|
|
|
|
static List *
|
|
|
|
|
get_relation_statistics(RelOptInfo *rel, Relation relation)
|
|
|
|
|
{
|
|
|
|
|
List *statoidlist;
|
|
|
|
|
List *stainfos = NIL;
|
|
|
|
|
ListCell *l;
|
|
|
|
|
|
|
|
|
|
statoidlist = RelationGetStatExtList(relation);
|
|
|
|
|
|
|
|
|
|
foreach(l, statoidlist)
|
|
|
|
|
{
|
|
|
|
|
Oid statOid = lfirst_oid(l);
|
|
|
|
|
Form_pg_statistic_ext staForm;
|
|
|
|
|
HeapTuple htup;
|
|
|
|
|
Bitmapset *keys = NULL;
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
htup = SearchSysCache1(STATEXTOID, ObjectIdGetDatum(statOid));
|
|
|
|
|
if (!htup)
|
|
|
|
|
elog(ERROR, "cache lookup failed for statistics object %u", statOid);
|
Implement multivariate n-distinct coefficients
Add support for explicitly declared statistic objects (CREATE
STATISTICS), allowing collection of statistics on more complex
combinations that individual table columns. Companion commands DROP
STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are
added too. All this DDL has been designed so that more statistic types
can be added later on, such as multivariate most-common-values and
multivariate histograms between columns of a single table, leaving room
for permitting columns on multiple tables, too, as well as expressions.
This commit only adds support for collection of n-distinct coefficient
on user-specified sets of columns in a single table. This is useful to
estimate number of distinct groups in GROUP BY and DISTINCT clauses;
estimation errors there can cause over-allocation of memory in hashed
aggregates, for instance, so it's a worthwhile problem to solve. A new
special pseudo-type pg_ndistinct is used.
(num-distinct estimation was deemed sufficiently useful by itself that
this is worthwhile even if no further statistic types are added
immediately; so much so that another version of essentially the same
functionality was submitted by Kyotaro Horiguchi:
https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp
though this commit does not use that code.)
Author: Tomas Vondra. Some code rework by Álvaro.
Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes,
Ideriha Takeshi
Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz
https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
8 years ago
|
|
|
staForm = (Form_pg_statistic_ext) GETSTRUCT(htup);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* First, build the array of columns covered. This is ultimately
|
|
|
|
|
* wasted if no stats within the object have actually been built, but
|
|
|
|
|
* it doesn't seem worth troubling over that case.
|
Implement multivariate n-distinct coefficients
Add support for explicitly declared statistic objects (CREATE
STATISTICS), allowing collection of statistics on more complex
combinations that individual table columns. Companion commands DROP
STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are
added too. All this DDL has been designed so that more statistic types
can be added later on, such as multivariate most-common-values and
multivariate histograms between columns of a single table, leaving room
for permitting columns on multiple tables, too, as well as expressions.
This commit only adds support for collection of n-distinct coefficient
on user-specified sets of columns in a single table. This is useful to
estimate number of distinct groups in GROUP BY and DISTINCT clauses;
estimation errors there can cause over-allocation of memory in hashed
aggregates, for instance, so it's a worthwhile problem to solve. A new
special pseudo-type pg_ndistinct is used.
(num-distinct estimation was deemed sufficiently useful by itself that
this is worthwhile even if no further statistic types are added
immediately; so much so that another version of essentially the same
functionality was submitted by Kyotaro Horiguchi:
https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp
though this commit does not use that code.)
Author: Tomas Vondra. Some code rework by Álvaro.
Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes,
Ideriha Takeshi
Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz
https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
8 years ago
|
|
|
*/
|
|
|
|
|
for (i = 0; i < staForm->stxkeys.dim1; i++)
|
|
|
|
|
keys = bms_add_member(keys, staForm->stxkeys.values[i]);
|
Implement multivariate n-distinct coefficients
Add support for explicitly declared statistic objects (CREATE
STATISTICS), allowing collection of statistics on more complex
combinations that individual table columns. Companion commands DROP
STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are
added too. All this DDL has been designed so that more statistic types
can be added later on, such as multivariate most-common-values and
multivariate histograms between columns of a single table, leaving room
for permitting columns on multiple tables, too, as well as expressions.
This commit only adds support for collection of n-distinct coefficient
on user-specified sets of columns in a single table. This is useful to
estimate number of distinct groups in GROUP BY and DISTINCT clauses;
estimation errors there can cause over-allocation of memory in hashed
aggregates, for instance, so it's a worthwhile problem to solve. A new
special pseudo-type pg_ndistinct is used.
(num-distinct estimation was deemed sufficiently useful by itself that
this is worthwhile even if no further statistic types are added
immediately; so much so that another version of essentially the same
functionality was submitted by Kyotaro Horiguchi:
https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp
though this commit does not use that code.)
Author: Tomas Vondra. Some code rework by Álvaro.
Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes,
Ideriha Takeshi
Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz
https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
8 years ago
|
|
|
|
|
|
|
|
/* add one StatisticExtInfo for each kind built */
|
|
|
|
|
if (statext_is_kind_built(htup, STATS_EXT_NDISTINCT))
|
|
|
|
|
{
|
|
|
|
|
StatisticExtInfo *info = makeNode(StatisticExtInfo);
|
|
|
|
|
|
|
|
|
|
info->statOid = statOid;
|
|
|
|
|
info->rel = rel;
|
|
|
|
|
info->kind = STATS_EXT_NDISTINCT;
|
|
|
|
|
info->keys = bms_copy(keys);
|
|
|
|
|
|
|
|
|
|
stainfos = lcons(info, stainfos);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (statext_is_kind_built(htup, STATS_EXT_DEPENDENCIES))
|
|
|
|
|
{
|
|
|
|
|
StatisticExtInfo *info = makeNode(StatisticExtInfo);
|
|
|
|
|
|
|
|
|
|
info->statOid = statOid;
|
|
|
|
|
info->rel = rel;
|
|
|
|
|
info->kind = STATS_EXT_DEPENDENCIES;
|
|
|
|
|
info->keys = bms_copy(keys);
|
|
|
|
|
|
Implement multivariate n-distinct coefficients
Add support for explicitly declared statistic objects (CREATE
STATISTICS), allowing collection of statistics on more complex
combinations that individual table columns. Companion commands DROP
STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are
added too. All this DDL has been designed so that more statistic types
can be added later on, such as multivariate most-common-values and
multivariate histograms between columns of a single table, leaving room
for permitting columns on multiple tables, too, as well as expressions.
This commit only adds support for collection of n-distinct coefficient
on user-specified sets of columns in a single table. This is useful to
estimate number of distinct groups in GROUP BY and DISTINCT clauses;
estimation errors there can cause over-allocation of memory in hashed
aggregates, for instance, so it's a worthwhile problem to solve. A new
special pseudo-type pg_ndistinct is used.
(num-distinct estimation was deemed sufficiently useful by itself that
this is worthwhile even if no further statistic types are added
immediately; so much so that another version of essentially the same
functionality was submitted by Kyotaro Horiguchi:
https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp
though this commit does not use that code.)
Author: Tomas Vondra. Some code rework by Álvaro.
Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes,
Ideriha Takeshi
Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz
https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
8 years ago
|
|
|
stainfos = lcons(info, stainfos);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ReleaseSysCache(htup);
|
|
|
|
|
bms_free(keys);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
list_free(statoidlist);
|
|
|
|
|
|
|
|
|
|
return stainfos;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* relation_excluded_by_constraints
|
|
|
|
|
*
|
|
|
|
|
* Detect whether the relation need not be scanned because it has either
|
|
|
|
|
* self-inconsistent restrictions, or restrictions inconsistent with the
|
|
|
|
|
* relation's validated CHECK constraints.
|
|
|
|
|
*
|
|
|
|
|
* Note: this examines only rel->relid, rel->reloptkind, and
|
|
|
|
|
* rel->baserestrictinfo; therefore it can be called before filling in
|
|
|
|
|
* other fields of the RelOptInfo.
|
|
|
|
|
*/
|
|
|
|
|
bool
|
|
|
|
|
relation_excluded_by_constraints(PlannerInfo *root,
|
|
|
|
|
RelOptInfo *rel, RangeTblEntry *rte)
|
|
|
|
|
{
|
|
|
|
|
List *safe_restrictions;
|
|
|
|
|
List *constraint_pred;
|
|
|
|
|
List *safe_constraints;
|
|
|
|
|
ListCell *lc;
|
|
|
|
|
|
Abstract logic to allow for multiple kinds of child rels.
Currently, the only type of child relation is an "other member rel",
which is the child of a baserel, but in the future joins and even
upper relations may have child rels. To facilitate that, introduce
macros that test to test for particular RelOptKind values, and use
them in various places where they help to clarify the sense of a test.
(For example, a test may allow RELOPT_OTHER_MEMBER_REL either because
it intends to allow child rels, or because it intends to allow simple
rels.)
Also, remove find_childrel_top_parent, which will not work for a
child rel that is not a baserel. Instead, add a new RelOptInfo
member top_parent_relids to track the same kind of information in a
more generic manner.
Ashutosh Bapat, slightly tweaked by me. Review and testing of the
patch set from which this was taken by Rajkumar Raghuwanshi and Rafia
Sabih.
Discussion: http://postgr.es/m/CA+TgmoagTnF2yqR3PT2rv=om=wJiZ4-A+ATwdnriTGku1CLYxA@mail.gmail.com
8 years ago
|
|
|
/* As of now, constraint exclusion works only with simple relations. */
|
|
|
|
|
Assert(IS_SIMPLE_REL(rel));
|
|
|
|
|
|
Make the upper part of the planner work by generating and comparing Paths.
I've been saying we needed to do this for more than five years, and here it
finally is. This patch removes the ever-growing tangle of spaghetti logic
that grouping_planner() used to use to try to identify the best plan for
post-scan/join query steps. Now, there is (nearly) independent
consideration of each execution step, and entirely separate construction of
Paths to represent each of the possible ways to do that step. We choose
the best Path or set of Paths using the same add_path() logic that's been
used inside query_planner() for years.
In addition, this patch removes the old restriction that subquery_planner()
could return only a single Plan. It now returns a RelOptInfo containing a
set of Paths, just as query_planner() does, and the parent query level can
use each of those Paths as the basis of a SubqueryScanPath at its level.
This allows finding some optimizations that we missed before, wherein a
subquery was capable of returning presorted data and thereby avoiding a
sort in the parent level, making the overall cost cheaper even though
delivering sorted output was not the cheapest plan for the subquery in
isolation. (A couple of regression test outputs change in consequence of
that. However, there is very little change in visible planner behavior
overall, because the point of this patch is not to get immediate planning
benefits but to create the infrastructure for future improvements.)
There is a great deal left to do here. This patch unblocks a lot of
planner work that was basically impractical in the old code structure,
such as allowing FDWs to implement remote aggregation, or rewriting
plan_set_operations() to allow consideration of multiple implementation
orders for set operations. (The latter will likely require a full
rewrite of plan_set_operations(); what I've done here is only to fix it
to return Paths not Plans.) I have also left unfinished some localized
refactoring in createplan.c and planner.c, because it was not necessary
to get this patch to a working state.
Thanks to Robert Haas, David Rowley, and Amit Kapila for review.
9 years ago
|
|
|
/*
|
|
|
|
|
* Regardless of the setting of constraint_exclusion, detect
|
|
|
|
|
* constant-FALSE-or-NULL restriction clauses. Because const-folding will
|
|
|
|
|
* reduce "anything AND FALSE" to just "FALSE", any such case should
|
|
|
|
|
* result in exactly one baserestrictinfo entry. This doesn't fire very
|
|
|
|
|
* often, but it seems cheap enough to be worth doing anyway. (Without
|
|
|
|
|
* this, we'd miss some optimizations that 9.5 and earlier found via much
|
|
|
|
|
* more roundabout methods.)
|
|
|
|
|
*/
|
|
|
|
|
if (list_length(rel->baserestrictinfo) == 1)
|
|
|
|
|
{
|
|
|
|
|
RestrictInfo *rinfo = (RestrictInfo *) linitial(rel->baserestrictinfo);
|
|
|
|
|
Expr *clause = rinfo->clause;
|
|
|
|
|
|
|
|
|
|
if (clause && IsA(clause, Const) &&
|
|
|
|
|
(((Const *) clause)->constisnull ||
|
|
|
|
|
!DatumGetBool(((Const *) clause)->constvalue)))
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Skip further tests, depending on constraint_exclusion.
|
|
|
|
|
*/
|
|
|
|
|
switch (constraint_exclusion)
|
|
|
|
|
{
|
|
|
|
|
case CONSTRAINT_EXCLUSION_OFF:
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Don't prune if feature turned off -- except if the relation is
|
|
|
|
|
* a partition. While partprune.c-style partition pruning is not
|
|
|
|
|
* yet in use for all cases (update/delete is not handled), it
|
|
|
|
|
* would be a UI horror to use different user-visible controls
|
|
|
|
|
* depending on such a volatile implementation detail. Therefore,
|
|
|
|
|
* for partitioned tables we use enable_partition_pruning to
|
|
|
|
|
* control this behavior.
|
|
|
|
|
*/
|
|
|
|
|
if (root->inhTargetKind == INHKIND_PARTITIONED)
|
|
|
|
|
break;
|
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
case CONSTRAINT_EXCLUSION_PARTITION:
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* When constraint_exclusion is set to 'partition' we only handle
|
|
|
|
|
* OTHER_MEMBER_RELs, or BASERELs in cases where the result target
|
|
|
|
|
* is an inheritance parent or a partitioned table.
|
|
|
|
|
*/
|
|
|
|
|
if ((rel->reloptkind != RELOPT_OTHER_MEMBER_REL) &&
|
|
|
|
|
!(rel->reloptkind == RELOPT_BASEREL &&
|
|
|
|
|
root->inhTargetKind != INHKIND_NONE &&
|
|
|
|
|
rel->relid == root->parse->resultRelation))
|
|
|
|
|
return false;
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case CONSTRAINT_EXCLUSION_ON:
|
|
|
|
|
break; /* always try to exclude */
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Check for self-contradictory restriction clauses. We dare not make
|
|
|
|
|
* deductions with non-immutable functions, but any immutable clauses that
|
|
|
|
|
* are self-contradictory allow us to conclude the scan is unnecessary.
|
|
|
|
|
*
|
|
|
|
|
* Note: strip off RestrictInfo because predicate_refuted_by() isn't
|
|
|
|
|
* expecting to see any in its predicate argument.
|
|
|
|
|
*/
|
|
|
|
|
safe_restrictions = NIL;
|
|
|
|
|
foreach(lc, rel->baserestrictinfo)
|
|
|
|
|
{
|
|
|
|
|
RestrictInfo *rinfo = (RestrictInfo *) lfirst(lc);
|
|
|
|
|
|
|
|
|
|
if (!contain_mutable_functions((Node *) rinfo->clause))
|
|
|
|
|
safe_restrictions = lappend(safe_restrictions, rinfo->clause);
|
|
|
|
|
}
|
|
|
|
|
|
Improve predtest.c's internal docs, and enhance its functionality a bit.
Commit b08df9cab left things rather poorly documented as far as the
exact semantics of "clause_is_check" mode went. Also, that mode did
not really work correctly for predicate_refuted_by; although given the
lack of specification as to what it should do, as well as the lack
of any actual use-case, that's perhaps not surprising.
Rename "clause_is_check" to "weak" proof mode, and provide specifications
for what it should do. I defined weak refutation as meaning "truth of A
implies non-truth of B", which makes it possible to use the mode in the
part of relation_excluded_by_constraints that checks for mutually
contradictory WHERE clauses. Fix up several places that did things wrong
for that definition. (As far as I can see, these errors would only lead
to failure-to-prove, not incorrect claims of proof, making them not
serious bugs even aside from the fact that v10 contains no use of this
mode. So there seems no need for back-patching.)
In addition, teach predicate_refuted_by_recurse that it can use
predicate_implied_by_recurse after all when processing a strong NOT-clause,
so long as it asks for the correct proof strength. This is an optimization
that could have been included in commit b08df9cab, but wasn't.
Also, simplify and generalize the logic that checks for whether nullness of
the argument of IS [NOT] NULL would force overall nullness of the predicate
or clause. (This results in a change in the partition_prune test's output,
as it is now able to prune an all-nulls partition that it did not recognize
before.)
In passing, in PartConstraintImpliedByRelConstraint, remove bogus
conversion of the constraint list to explicit-AND form and then right back
again; that accomplished nothing except forcing a useless extra level of
recursion inside predicate_implied_by.
Discussion: https://postgr.es/m/5983.1520487191@sss.pgh.pa.us
7 years ago
|
|
|
/*
|
|
|
|
|
* We can use weak refutation here, since we're comparing restriction
|
|
|
|
|
* clauses with restriction clauses.
|
|
|
|
|
*/
|
|
|
|
|
if (predicate_refuted_by(safe_restrictions, safe_restrictions, true))
|
|
|
|
|
return true;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Only plain relations have constraints. In a partitioning hierarchy,
|
|
|
|
|
* but not with regular table inheritance, it's OK to assume that any
|
|
|
|
|
* constraints that hold for the parent also hold for every child; for
|
|
|
|
|
* instance, table inheritance allows the parent to have constraints
|
|
|
|
|
* marked NO INHERIT, but table partitioning does not. We choose to check
|
|
|
|
|
* whether the partitioning parents can be excluded here; doing so
|
|
|
|
|
* consumes some cycles, but potentially saves us the work of excluding
|
|
|
|
|
* each child individually.
|
|
|
|
|
*/
|
|
|
|
|
if (rte->rtekind != RTE_RELATION ||
|
|
|
|
|
(rte->inh && rte->relkind != RELKIND_PARTITIONED_TABLE))
|
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* OK to fetch the constraint expressions. Include "col IS NOT NULL"
|
|
|
|
|
* expressions for attnotnull columns, in case we can refute those.
|
|
|
|
|
*/
|
|
|
|
|
constraint_pred = get_relation_constraints(root, rte->relid, rel, true);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* We do not currently enforce that CHECK constraints contain only
|
|
|
|
|
* immutable functions, so it's necessary to check here. We daren't draw
|
|
|
|
|
* conclusions from plan-time evaluation of non-immutable functions. Since
|
|
|
|
|
* they're ANDed, we can just ignore any mutable constraints in the list,
|
|
|
|
|
* and reason about the rest.
|
|
|
|
|
*/
|
|
|
|
|
safe_constraints = NIL;
|
|
|
|
|
foreach(lc, constraint_pred)
|
|
|
|
|
{
|
|
|
|
|
Node *pred = (Node *) lfirst(lc);
|
|
|
|
|
|
|
|
|
|
if (!contain_mutable_functions(pred))
|
|
|
|
|
safe_constraints = lappend(safe_constraints, pred);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* The constraints are effectively ANDed together, so we can just try to
|
|
|
|
|
* refute the entire collection at once. This may allow us to make proofs
|
|
|
|
|
* that would fail if we took them individually.
|
|
|
|
|
*
|
|
|
|
|
* Note: we use rel->baserestrictinfo, not safe_restrictions as might seem
|
|
|
|
|
* an obvious optimization. Some of the clauses might be OR clauses that
|
|
|
|
|
* have volatile and nonvolatile subclauses, and it's OK to make
|
|
|
|
|
* deductions with the nonvolatile parts.
|
Improve predtest.c's internal docs, and enhance its functionality a bit.
Commit b08df9cab left things rather poorly documented as far as the
exact semantics of "clause_is_check" mode went. Also, that mode did
not really work correctly for predicate_refuted_by; although given the
lack of specification as to what it should do, as well as the lack
of any actual use-case, that's perhaps not surprising.
Rename "clause_is_check" to "weak" proof mode, and provide specifications
for what it should do. I defined weak refutation as meaning "truth of A
implies non-truth of B", which makes it possible to use the mode in the
part of relation_excluded_by_constraints that checks for mutually
contradictory WHERE clauses. Fix up several places that did things wrong
for that definition. (As far as I can see, these errors would only lead
to failure-to-prove, not incorrect claims of proof, making them not
serious bugs even aside from the fact that v10 contains no use of this
mode. So there seems no need for back-patching.)
In addition, teach predicate_refuted_by_recurse that it can use
predicate_implied_by_recurse after all when processing a strong NOT-clause,
so long as it asks for the correct proof strength. This is an optimization
that could have been included in commit b08df9cab, but wasn't.
Also, simplify and generalize the logic that checks for whether nullness of
the argument of IS [NOT] NULL would force overall nullness of the predicate
or clause. (This results in a change in the partition_prune test's output,
as it is now able to prune an all-nulls partition that it did not recognize
before.)
In passing, in PartConstraintImpliedByRelConstraint, remove bogus
conversion of the constraint list to explicit-AND form and then right back
again; that accomplished nothing except forcing a useless extra level of
recursion inside predicate_implied_by.
Discussion: https://postgr.es/m/5983.1520487191@sss.pgh.pa.us
7 years ago
|
|
|
*
|
|
|
|
|
* We need strong refutation because we have to prove that the constraints
|
|
|
|
|
* would yield false, not just NULL.
|
|
|
|
|
*/
|
|
|
|
|
if (predicate_refuted_by(safe_constraints, rel->baserestrictinfo, false))
|
|
|
|
|
return true;
|
|
|
|
|
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* build_physical_tlist
|
|
|
|
|
*
|
|
|
|
|
* Build a targetlist consisting of exactly the relation's user attributes,
|
|
|
|
|
* in order. The executor can special-case such tlists to avoid a projection
|
|
|
|
|
* step at runtime, so we use such tlists preferentially for scan nodes.
|
|
|
|
|
*
|
|
|
|
|
* Exception: if there are any dropped or missing columns, we punt and return
|
|
|
|
|
* NIL. Ideally we would like to handle these cases too. However this
|
|
|
|
|
* creates problems for ExecTypeFromTL, which may be asked to build a tupdesc
|
|
|
|
|
* for a tlist that includes vars of no-longer-existent types. In theory we
|
|
|
|
|
* could dig out the required info from the pg_attribute entries of the
|
|
|
|
|
* relation, but that data is not readily available to ExecTypeFromTL.
|
|
|
|
|
* For now, we don't apply the physical-tlist optimization when there are
|
|
|
|
|
* dropped cols.
|
|
|
|
|
*
|
|
|
|
|
* We also support building a "physical" tlist for subqueries, functions,
|
|
|
|
|
* values lists, table expressions, and CTEs, since the same optimization can
|
|
|
|
|
* occur in SubqueryScan, FunctionScan, ValuesScan, CteScan, TableFunc,
|
|
|
|
|
* NamedTuplestoreScan, and WorkTableScan nodes.
|
|
|
|
|
*/
|
|
|
|
|
List *
|
|
|
|
|
build_physical_tlist(PlannerInfo *root, RelOptInfo *rel)
|
|
|
|
|
{
|
|
|
|
|
List *tlist = NIL;
|
|
|
|
|
Index varno = rel->relid;
|
|
|
|
|
RangeTblEntry *rte = planner_rt_fetch(varno, root);
|
|
|
|
|
Relation relation;
|
|
|
|
|
Query *subquery;
|
|
|
|
|
Var *var;
|
|
|
|
|
ListCell *l;
|
|
|
|
|
int attrno,
|
|
|
|
|
numattrs;
|
|
|
|
|
List *colvars;
|
|
|
|
|
|
|
|
|
|
switch (rte->rtekind)
|
|
|
|
|
{
|
|
|
|
|
case RTE_RELATION:
|
|
|
|
|
/* Assume we already have adequate lock */
|
|
|
|
|
relation = heap_open(rte->relid, NoLock);
|
|
|
|
|
|
|
|
|
|
numattrs = RelationGetNumberOfAttributes(relation);
|
|
|
|
|
for (attrno = 1; attrno <= numattrs; attrno++)
|
|
|
|
|
{
|
|
|
|
|
Form_pg_attribute att_tup = TupleDescAttr(relation->rd_att,
|
|
|
|
|
attrno - 1);
|
|
|
|
|
|
|
|
|
|
if (att_tup->attisdropped || att_tup->atthasmissing)
|
|
|
|
|
{
|
|
|
|
|
/* found a dropped or missing col, so punt */
|
|
|
|
|
tlist = NIL;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
var = makeVar(varno,
|
|
|
|
|
attrno,
|
|
|
|
|
att_tup->atttypid,
|
|
|
|
|
att_tup->atttypmod,
|
|
|
|
|
att_tup->attcollation,
|
|
|
|
|
0);
|
|
|
|
|
|
|
|
|
|
tlist = lappend(tlist,
|
|
|
|
|
makeTargetEntry((Expr *) var,
|
|
|
|
|
attrno,
|
|
|
|
|
NULL,
|
|
|
|
|
false));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
heap_close(relation, NoLock);
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case RTE_SUBQUERY:
|
|
|
|
|
subquery = rte->subquery;
|
|
|
|
|
foreach(l, subquery->targetList)
|
|
|
|
|
{
|
|
|
|
|
TargetEntry *tle = (TargetEntry *) lfirst(l);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* A resjunk column of the subquery can be reflected as
|
|
|
|
|
* resjunk in the physical tlist; we need not punt.
|
|
|
|
|
*/
|
|
|
|
|
var = makeVarFromTargetEntry(varno, tle);
|
|
|
|
|
|
|
|
|
|
tlist = lappend(tlist,
|
|
|
|
|
makeTargetEntry((Expr *) var,
|
|
|
|
|
tle->resno,
|
|
|
|
|
NULL,
|
|
|
|
|
tle->resjunk));
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case RTE_FUNCTION:
|
|
|
|
|
case RTE_TABLEFUNC:
|
|
|
|
|
case RTE_VALUES:
|
|
|
|
|
case RTE_CTE:
|
|
|
|
|
case RTE_NAMEDTUPLESTORE:
|
|
|
|
|
/* Not all of these can have dropped cols, but share code anyway */
|
|
|
|
|
expandRTE(rte, varno, 0, -1, true /* include dropped */ ,
|
|
|
|
|
NULL, &colvars);
|
|
|
|
|
foreach(l, colvars)
|
|
|
|
|
{
|
|
|
|
|
var = (Var *) lfirst(l);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* A non-Var in expandRTE's output means a dropped column;
|
|
|
|
|
* must punt.
|
|
|
|
|
*/
|
|
|
|
|
if (!IsA(var, Var))
|
|
|
|
|
{
|
|
|
|
|
tlist = NIL;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
tlist = lappend(tlist,
|
|
|
|
|
makeTargetEntry((Expr *) var,
|
|
|
|
|
var->varattno,
|
|
|
|
|
NULL,
|
|
|
|
|
false));
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
default:
|
|
|
|
|
/* caller error */
|
|
|
|
|
elog(ERROR, "unsupported RTE kind %d in build_physical_tlist",
|
|
|
|
|
(int) rte->rtekind);
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return tlist;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* build_index_tlist
|
|
|
|
|
*
|
|
|
|
|
* Build a targetlist representing the columns of the specified index.
|
|
|
|
|
* Each column is represented by a Var for the corresponding base-relation
|
|
|
|
|
* column, or an expression in base-relation Vars, as appropriate.
|
|
|
|
|
*
|
|
|
|
|
* There are never any dropped columns in indexes, so unlike
|
|
|
|
|
* build_physical_tlist, we need no failure case.
|
|
|
|
|
*/
|
|
|
|
|
static List *
|
|
|
|
|
build_index_tlist(PlannerInfo *root, IndexOptInfo *index,
|
|
|
|
|
Relation heapRelation)
|
|
|
|
|
{
|
|
|
|
|
List *tlist = NIL;
|
|
|
|
|
Index varno = index->rel->relid;
|
|
|
|
|
ListCell *indexpr_item;
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
indexpr_item = list_head(index->indexprs);
|
|
|
|
|
for (i = 0; i < index->ncolumns; i++)
|
|
|
|
|
{
|
|
|
|
|
int indexkey = index->indexkeys[i];
|
|
|
|
|
Expr *indexvar;
|
|
|
|
|
|
|
|
|
|
if (indexkey != 0)
|
|
|
|
|
{
|
|
|
|
|
/* simple column */
|
|
|
|
|
const FormData_pg_attribute *att_tup;
|
|
|
|
|
|
|
|
|
|
if (indexkey < 0)
|
|
|
|
|
att_tup = SystemAttributeDefinition(indexkey,
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
8 years ago
|
|
|
heapRelation->rd_rel->relhasoids);
|
|
|
|
|
else
|
|
|
|
|
att_tup = TupleDescAttr(heapRelation->rd_att, indexkey - 1);
|
|
|
|
|
|
|
|
|
|
indexvar = (Expr *) makeVar(varno,
|
|
|
|
|
indexkey,
|
|
|
|
|
att_tup->atttypid,
|
|
|
|
|
att_tup->atttypmod,
|
|
|
|
|
att_tup->attcollation,
|
|
|
|
|
0);
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
/* expression column */
|
|
|
|
|
if (indexpr_item == NULL)
|
|
|
|
|
elog(ERROR, "wrong number of index expressions");
|
|
|
|
|
indexvar = (Expr *) lfirst(indexpr_item);
|
|
|
|
|
indexpr_item = lnext(indexpr_item);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
tlist = lappend(tlist,
|
|
|
|
|
makeTargetEntry(indexvar,
|
|
|
|
|
i + 1,
|
|
|
|
|
NULL,
|
|
|
|
|
false));
|
|
|
|
|
}
|
|
|
|
|
if (indexpr_item != NULL)
|
|
|
|
|
elog(ERROR, "wrong number of index expressions");
|
|
|
|
|
|
|
|
|
|
return tlist;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* restriction_selectivity
|
|
|
|
|
*
|
|
|
|
|
* Returns the selectivity of a specified restriction operator clause.
|
|
|
|
|
* This code executes registered procedures stored in the
|
|
|
|
|
* operator relation, by calling the function manager.
|
|
|
|
|
*
|
|
|
|
|
* See clause_selectivity() for the meaning of the additional parameters.
|
|
|
|
|
*/
|
|
|
|
|
Selectivity
|
|
|
|
|
restriction_selectivity(PlannerInfo *root,
|
|
|
|
|
Oid operatorid,
|
|
|
|
|
List *args,
|
|
|
|
|
Oid inputcollid,
|
|
|
|
|
int varRelid)
|
|
|
|
|
{
|
|
|
|
|
RegProcedure oprrest = get_oprrest(operatorid);
|
|
|
|
|
float8 result;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* if the oprrest procedure is missing for whatever reason, use a
|
|
|
|
|
* selectivity of 0.5
|
|
|
|
|
*/
|
|
|
|
|
if (!oprrest)
|
|
|
|
|
return (Selectivity) 0.5;
|
|
|
|
|
|
|
|
|
|
result = DatumGetFloat8(OidFunctionCall4Coll(oprrest,
|
|
|
|
|
inputcollid,
|
|
|
|
|
PointerGetDatum(root),
|
|
|
|
|
ObjectIdGetDatum(operatorid),
|
|
|
|
|
PointerGetDatum(args),
|
|
|
|
|
Int32GetDatum(varRelid)));
|
|
|
|
|
|
|
|
|
|
if (result < 0.0 || result > 1.0)
|
|
|
|
|
elog(ERROR, "invalid restriction selectivity: %f", result);
|
|
|
|
|
|
|
|
|
|
return (Selectivity) result;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* join_selectivity
|
|
|
|
|
*
|
|
|
|
|
* Returns the selectivity of a specified join operator clause.
|
|
|
|
|
* This code executes registered procedures stored in the
|
|
|
|
|
* operator relation, by calling the function manager.
|
|
|
|
|
*/
|
|
|
|
|
Selectivity
|
|
|
|
|
join_selectivity(PlannerInfo *root,
|
|
|
|
|
Oid operatorid,
|
|
|
|
|
List *args,
|
|
|
|
|
Oid inputcollid,
|
|
|
|
|
JoinType jointype,
|
|
|
|
|
SpecialJoinInfo *sjinfo)
|
|
|
|
|
{
|
|
|
|
|
RegProcedure oprjoin = get_oprjoin(operatorid);
|
|
|
|
|
float8 result;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* if the oprjoin procedure is missing for whatever reason, use a
|
|
|
|
|
* selectivity of 0.5
|
|
|
|
|
*/
|
|
|
|
|
if (!oprjoin)
|
|
|
|
|
return (Selectivity) 0.5;
|
|
|
|
|
|
|
|
|
|
result = DatumGetFloat8(OidFunctionCall5Coll(oprjoin,
|
|
|
|
|
inputcollid,
|
|
|
|
|
PointerGetDatum(root),
|
|
|
|
|
ObjectIdGetDatum(operatorid),
|
|
|
|
|
PointerGetDatum(args),
|
|
|
|
|
Int16GetDatum(jointype),
|
|
|
|
|
PointerGetDatum(sjinfo)));
|
|
|
|
|
|
|
|
|
|
if (result < 0.0 || result > 1.0)
|
|
|
|
|
elog(ERROR, "invalid join selectivity: %f", result);
|
|
|
|
|
|
|
|
|
|
return (Selectivity) result;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* has_unique_index
|
|
|
|
|
*
|
|
|
|
|
* Detect whether there is a unique index on the specified attribute
|
|
|
|
|
* of the specified relation, thus allowing us to conclude that all
|
|
|
|
|
* the (non-null) values of the attribute are distinct.
|
|
|
|
|
*
|
|
|
|
|
* This function does not check the index's indimmediate property, which
|
|
|
|
|
* means that uniqueness may transiently fail to hold intra-transaction.
|
|
|
|
|
* That's appropriate when we are making statistical estimates, but beware
|
|
|
|
|
* of using this for any correctness proofs.
|
|
|
|
|
*/
|
|
|
|
|
bool
|
|
|
|
|
has_unique_index(RelOptInfo *rel, AttrNumber attno)
|
|
|
|
|
{
|
|
|
|
|
ListCell *ilist;
|
|
|
|
|
|
|
|
|
|
foreach(ilist, rel->indexlist)
|
|
|
|
|
{
|
|
|
|
|
IndexOptInfo *index = (IndexOptInfo *) lfirst(ilist);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Note: ignore partial indexes, since they don't allow us to conclude
|
|
|
|
|
* that all attr values are distinct, *unless* they are marked predOK
|
|
|
|
|
* which means we know the index's predicate is satisfied by the
|
|
|
|
|
* query. We don't take any interest in expressional indexes either.
|
|
|
|
|
* Also, a multicolumn unique index doesn't allow us to conclude that
|
|
|
|
|
* just the specified attr is unique.
|
|
|
|
|
*/
|
|
|
|
|
if (index->unique &&
|
|
|
|
|
index->nkeycolumns == 1 &&
|
|
|
|
|
index->indexkeys[0] == attno &&
|
|
|
|
|
(index->indpred == NIL || index->predOK))
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* has_row_triggers
|
|
|
|
|
*
|
|
|
|
|
* Detect whether the specified relation has any row-level triggers for event.
|
|
|
|
|
*/
|
|
|
|
|
bool
|
|
|
|
|
has_row_triggers(PlannerInfo *root, Index rti, CmdType event)
|
|
|
|
|
{
|
|
|
|
|
RangeTblEntry *rte = planner_rt_fetch(rti, root);
|
|
|
|
|
Relation relation;
|
|
|
|
|
TriggerDesc *trigDesc;
|
|
|
|
|
bool result = false;
|
|
|
|
|
|
|
|
|
|
/* Assume we already have adequate lock */
|
|
|
|
|
relation = heap_open(rte->relid, NoLock);
|
|
|
|
|
|
|
|
|
|
trigDesc = relation->trigdesc;
|
|
|
|
|
switch (event)
|
|
|
|
|
{
|
|
|
|
|
case CMD_INSERT:
|
|
|
|
|
if (trigDesc &&
|
|
|
|
|
(trigDesc->trig_insert_after_row ||
|
|
|
|
|
trigDesc->trig_insert_before_row))
|
|
|
|
|
result = true;
|
|
|
|
|
break;
|
|
|
|
|
case CMD_UPDATE:
|
|
|
|
|
if (trigDesc &&
|
|
|
|
|
(trigDesc->trig_update_after_row ||
|
|
|
|
|
trigDesc->trig_update_before_row))
|
|
|
|
|
result = true;
|
|
|
|
|
break;
|
|
|
|
|
case CMD_DELETE:
|
|
|
|
|
if (trigDesc &&
|
|
|
|
|
(trigDesc->trig_delete_after_row ||
|
|
|
|
|
trigDesc->trig_delete_before_row))
|
|
|
|
|
result = true;
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
elog(ERROR, "unrecognized CmdType: %d", (int) event);
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
heap_close(relation, NoLock);
|
|
|
|
|
return result;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* set_relation_partition_info
|
|
|
|
|
*
|
|
|
|
|
* Set partitioning scheme and related information for a partitioned table.
|
|
|
|
|
*/
|
|
|
|
|
static void
|
|
|
|
|
set_relation_partition_info(PlannerInfo *root, RelOptInfo *rel,
|
|
|
|
|
Relation relation)
|
|
|
|
|
{
|
|
|
|
|
PartitionDesc partdesc;
|
|
|
|
|
PartitionKey partkey;
|
|
|
|
|
|
|
|
|
|
Assert(relation->rd_rel->relkind == RELKIND_PARTITIONED_TABLE);
|
|
|
|
|
|
|
|
|
|
partdesc = RelationGetPartitionDesc(relation);
|
|
|
|
|
partkey = RelationGetPartitionKey(relation);
|
|
|
|
|
rel->part_scheme = find_partition_scheme(root, relation);
|
|
|
|
|
Assert(partdesc != NULL && rel->part_scheme != NULL);
|
|
|
|
|
rel->boundinfo = partition_bounds_copy(partdesc->boundinfo, partkey);
|
|
|
|
|
rel->nparts = partdesc->nparts;
|
Basic partition-wise join functionality.
Instead of joining two partitioned tables in their entirety we can, if
it is an equi-join on the partition keys, join the matching partitions
individually. This involves teaching the planner about "other join"
rels, which are related to regular join rels in the same way that
other member rels are related to baserels. This can use significantly
more CPU time and memory than regular join planning, because there may
now be a set of "other" rels not only for every base relation but also
for every join relation. In most practical cases, this probably
shouldn't be a problem, because (1) it's probably unusual to join many
tables each with many partitions using the partition keys for all
joins and (2) if you do that scenario then you probably have a big
enough machine to handle the increased memory cost of planning and (3)
the resulting plan is highly likely to be better, so what you spend in
planning you'll make up on the execution side. All the same, for now,
turn this feature off by default.
Currently, we can only perform joins between two tables whose
partitioning schemes are absolutely identical. It would be nice to
cope with other scenarios, such as extra partitions on one side or the
other with no match on the other side, but that will have to wait for
a future patch.
Ashutosh Bapat, reviewed and tested by Rajkumar Raghuwanshi, Amit
Langote, Rafia Sabih, Thomas Munro, Dilip Kumar, Antonin Houska, Amit
Khandekar, and by me. A few final adjustments by me.
Discussion: http://postgr.es/m/CAFjFpRfQ8GrQvzp3jA2wnLqrHmaXna-urjm_UY9BqXj=EaDTSA@mail.gmail.com
Discussion: http://postgr.es/m/CAFjFpRcitjfrULr5jfuKWRPsGUX0LQ0k8-yG0Qw2+1LBGNpMdw@mail.gmail.com
8 years ago
|
|
|
set_baserel_partition_key_exprs(relation, rel);
|
Faster partition pruning
Add a new module backend/partitioning/partprune.c, implementing a more
sophisticated algorithm for partition pruning. The new module uses each
partition's "boundinfo" for pruning instead of constraint exclusion,
based on an idea proposed by Robert Haas of a "pruning program": a list
of steps generated from the query quals which are run iteratively to
obtain a list of partitions that must be scanned in order to satisfy
those quals.
At present, this targets planner-time partition pruning, but there exist
further patches to apply partition pruning at execution time as well.
This commit also moves some definitions from include/catalog/partition.h
to a new file include/partitioning/partbounds.h, in an attempt to
rationalize partitioning related code.
Authors: Amit Langote, David Rowley, Dilip Kumar
Reviewers: Robert Haas, Kyotaro Horiguchi, Ashutosh Bapat, Jesper Pedersen.
Discussion: https://postgr.es/m/098b9c71-1915-1a2a-8d52-1a7a50ce79e8@lab.ntt.co.jp
7 years ago
|
|
|
rel->partition_qual = RelationGetPartitionQual(relation);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* find_partition_scheme
|
|
|
|
|
*
|
|
|
|
|
* Find or create a PartitionScheme for this Relation.
|
|
|
|
|
*/
|
|
|
|
|
static PartitionScheme
|
|
|
|
|
find_partition_scheme(PlannerInfo *root, Relation relation)
|
|
|
|
|
{
|
|
|
|
|
PartitionKey partkey = RelationGetPartitionKey(relation);
|
|
|
|
|
ListCell *lc;
|
Faster partition pruning
Add a new module backend/partitioning/partprune.c, implementing a more
sophisticated algorithm for partition pruning. The new module uses each
partition's "boundinfo" for pruning instead of constraint exclusion,
based on an idea proposed by Robert Haas of a "pruning program": a list
of steps generated from the query quals which are run iteratively to
obtain a list of partitions that must be scanned in order to satisfy
those quals.
At present, this targets planner-time partition pruning, but there exist
further patches to apply partition pruning at execution time as well.
This commit also moves some definitions from include/catalog/partition.h
to a new file include/partitioning/partbounds.h, in an attempt to
rationalize partitioning related code.
Authors: Amit Langote, David Rowley, Dilip Kumar
Reviewers: Robert Haas, Kyotaro Horiguchi, Ashutosh Bapat, Jesper Pedersen.
Discussion: https://postgr.es/m/098b9c71-1915-1a2a-8d52-1a7a50ce79e8@lab.ntt.co.jp
7 years ago
|
|
|
int partnatts,
|
|
|
|
|
i;
|
|
|
|
|
PartitionScheme part_scheme;
|
|
|
|
|
|
|
|
|
|
/* A partitioned table should have a partition key. */
|
|
|
|
|
Assert(partkey != NULL);
|
|
|
|
|
|
|
|
|
|
partnatts = partkey->partnatts;
|
|
|
|
|
|
|
|
|
|
/* Search for a matching partition scheme and return if found one. */
|
|
|
|
|
foreach(lc, root->part_schemes)
|
|
|
|
|
{
|
|
|
|
|
part_scheme = lfirst(lc);
|
|
|
|
|
|
|
|
|
|
/* Match partitioning strategy and number of keys. */
|
|
|
|
|
if (partkey->strategy != part_scheme->strategy ||
|
|
|
|
|
partnatts != part_scheme->partnatts)
|
|
|
|
|
continue;
|
|
|
|
|
|
Faster partition pruning
Add a new module backend/partitioning/partprune.c, implementing a more
sophisticated algorithm for partition pruning. The new module uses each
partition's "boundinfo" for pruning instead of constraint exclusion,
based on an idea proposed by Robert Haas of a "pruning program": a list
of steps generated from the query quals which are run iteratively to
obtain a list of partitions that must be scanned in order to satisfy
those quals.
At present, this targets planner-time partition pruning, but there exist
further patches to apply partition pruning at execution time as well.
This commit also moves some definitions from include/catalog/partition.h
to a new file include/partitioning/partbounds.h, in an attempt to
rationalize partitioning related code.
Authors: Amit Langote, David Rowley, Dilip Kumar
Reviewers: Robert Haas, Kyotaro Horiguchi, Ashutosh Bapat, Jesper Pedersen.
Discussion: https://postgr.es/m/098b9c71-1915-1a2a-8d52-1a7a50ce79e8@lab.ntt.co.jp
7 years ago
|
|
|
/* Match partition key type properties. */
|
|
|
|
|
if (memcmp(partkey->partopfamily, part_scheme->partopfamily,
|
|
|
|
|
sizeof(Oid) * partnatts) != 0 ||
|
|
|
|
|
memcmp(partkey->partopcintype, part_scheme->partopcintype,
|
|
|
|
|
sizeof(Oid) * partnatts) != 0 ||
|
|
|
|
|
memcmp(partkey->partcollation, part_scheme->partcollation,
|
|
|
|
|
sizeof(Oid) * partnatts) != 0)
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Length and byval information should match when partopcintype
|
|
|
|
|
* matches.
|
|
|
|
|
*/
|
|
|
|
|
Assert(memcmp(partkey->parttyplen, part_scheme->parttyplen,
|
|
|
|
|
sizeof(int16) * partnatts) == 0);
|
|
|
|
|
Assert(memcmp(partkey->parttypbyval, part_scheme->parttypbyval,
|
|
|
|
|
sizeof(bool) * partnatts) == 0);
|
|
|
|
|
|
Faster partition pruning
Add a new module backend/partitioning/partprune.c, implementing a more
sophisticated algorithm for partition pruning. The new module uses each
partition's "boundinfo" for pruning instead of constraint exclusion,
based on an idea proposed by Robert Haas of a "pruning program": a list
of steps generated from the query quals which are run iteratively to
obtain a list of partitions that must be scanned in order to satisfy
those quals.
At present, this targets planner-time partition pruning, but there exist
further patches to apply partition pruning at execution time as well.
This commit also moves some definitions from include/catalog/partition.h
to a new file include/partitioning/partbounds.h, in an attempt to
rationalize partitioning related code.
Authors: Amit Langote, David Rowley, Dilip Kumar
Reviewers: Robert Haas, Kyotaro Horiguchi, Ashutosh Bapat, Jesper Pedersen.
Discussion: https://postgr.es/m/098b9c71-1915-1a2a-8d52-1a7a50ce79e8@lab.ntt.co.jp
7 years ago
|
|
|
/*
|
|
|
|
|
* If partopfamily and partopcintype matched, must have the same
|
|
|
|
|
* partition comparison functions. Note that we cannot reliably
|
|
|
|
|
* Assert the equality of function structs themselves for they might
|
|
|
|
|
* be different across PartitionKey's, so just Assert for the function
|
|
|
|
|
* OIDs.
|
|
|
|
|
*/
|
|
|
|
|
#ifdef USE_ASSERT_CHECKING
|
|
|
|
|
for (i = 0; i < partkey->partnatts; i++)
|
|
|
|
|
Assert(partkey->partsupfunc[i].fn_oid ==
|
|
|
|
|
part_scheme->partsupfunc[i].fn_oid);
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
/* Found matching partition scheme. */
|
|
|
|
|
return part_scheme;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Did not find matching partition scheme. Create one copying relevant
|
|
|
|
|
* information from the relcache. We need to copy the contents of the
|
|
|
|
|
* array since the relcache entry may not survive after we have closed the
|
|
|
|
|
* relation.
|
|
|
|
|
*/
|
|
|
|
|
part_scheme = (PartitionScheme) palloc0(sizeof(PartitionSchemeData));
|
|
|
|
|
part_scheme->strategy = partkey->strategy;
|
|
|
|
|
part_scheme->partnatts = partkey->partnatts;
|
|
|
|
|
|
|
|
|
|
part_scheme->partopfamily = (Oid *) palloc(sizeof(Oid) * partnatts);
|
|
|
|
|
memcpy(part_scheme->partopfamily, partkey->partopfamily,
|
|
|
|
|
sizeof(Oid) * partnatts);
|
|
|
|
|
|
|
|
|
|
part_scheme->partopcintype = (Oid *) palloc(sizeof(Oid) * partnatts);
|
|
|
|
|
memcpy(part_scheme->partopcintype, partkey->partopcintype,
|
|
|
|
|
sizeof(Oid) * partnatts);
|
|
|
|
|
|
|
|
|
|
part_scheme->partcollation = (Oid *) palloc(sizeof(Oid) * partnatts);
|
|
|
|
|
memcpy(part_scheme->partcollation, partkey->partcollation,
|
|
|
|
|
sizeof(Oid) * partnatts);
|
|
|
|
|
|
|
|
|
|
part_scheme->parttyplen = (int16 *) palloc(sizeof(int16) * partnatts);
|
|
|
|
|
memcpy(part_scheme->parttyplen, partkey->parttyplen,
|
|
|
|
|
sizeof(int16) * partnatts);
|
|
|
|
|
|
|
|
|
|
part_scheme->parttypbyval = (bool *) palloc(sizeof(bool) * partnatts);
|
|
|
|
|
memcpy(part_scheme->parttypbyval, partkey->parttypbyval,
|
|
|
|
|
sizeof(bool) * partnatts);
|
|
|
|
|
|
Faster partition pruning
Add a new module backend/partitioning/partprune.c, implementing a more
sophisticated algorithm for partition pruning. The new module uses each
partition's "boundinfo" for pruning instead of constraint exclusion,
based on an idea proposed by Robert Haas of a "pruning program": a list
of steps generated from the query quals which are run iteratively to
obtain a list of partitions that must be scanned in order to satisfy
those quals.
At present, this targets planner-time partition pruning, but there exist
further patches to apply partition pruning at execution time as well.
This commit also moves some definitions from include/catalog/partition.h
to a new file include/partitioning/partbounds.h, in an attempt to
rationalize partitioning related code.
Authors: Amit Langote, David Rowley, Dilip Kumar
Reviewers: Robert Haas, Kyotaro Horiguchi, Ashutosh Bapat, Jesper Pedersen.
Discussion: https://postgr.es/m/098b9c71-1915-1a2a-8d52-1a7a50ce79e8@lab.ntt.co.jp
7 years ago
|
|
|
part_scheme->partsupfunc = (FmgrInfo *)
|
|
|
|
|
palloc(sizeof(FmgrInfo) * partnatts);
|
|
|
|
|
for (i = 0; i < partnatts; i++)
|
|
|
|
|
fmgr_info_copy(&part_scheme->partsupfunc[i], &partkey->partsupfunc[i],
|
|
|
|
|
CurrentMemoryContext);
|
|
|
|
|
|
|
|
|
|
/* Add the partitioning scheme to PlannerInfo. */
|
|
|
|
|
root->part_schemes = lappend(root->part_schemes, part_scheme);
|
|
|
|
|
|
|
|
|
|
return part_scheme;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
Basic partition-wise join functionality.
Instead of joining two partitioned tables in their entirety we can, if
it is an equi-join on the partition keys, join the matching partitions
individually. This involves teaching the planner about "other join"
rels, which are related to regular join rels in the same way that
other member rels are related to baserels. This can use significantly
more CPU time and memory than regular join planning, because there may
now be a set of "other" rels not only for every base relation but also
for every join relation. In most practical cases, this probably
shouldn't be a problem, because (1) it's probably unusual to join many
tables each with many partitions using the partition keys for all
joins and (2) if you do that scenario then you probably have a big
enough machine to handle the increased memory cost of planning and (3)
the resulting plan is highly likely to be better, so what you spend in
planning you'll make up on the execution side. All the same, for now,
turn this feature off by default.
Currently, we can only perform joins between two tables whose
partitioning schemes are absolutely identical. It would be nice to
cope with other scenarios, such as extra partitions on one side or the
other with no match on the other side, but that will have to wait for
a future patch.
Ashutosh Bapat, reviewed and tested by Rajkumar Raghuwanshi, Amit
Langote, Rafia Sabih, Thomas Munro, Dilip Kumar, Antonin Houska, Amit
Khandekar, and by me. A few final adjustments by me.
Discussion: http://postgr.es/m/CAFjFpRfQ8GrQvzp3jA2wnLqrHmaXna-urjm_UY9BqXj=EaDTSA@mail.gmail.com
Discussion: http://postgr.es/m/CAFjFpRcitjfrULr5jfuKWRPsGUX0LQ0k8-yG0Qw2+1LBGNpMdw@mail.gmail.com
8 years ago
|
|
|
* set_baserel_partition_key_exprs
|
|
|
|
|
*
|
Basic partition-wise join functionality.
Instead of joining two partitioned tables in their entirety we can, if
it is an equi-join on the partition keys, join the matching partitions
individually. This involves teaching the planner about "other join"
rels, which are related to regular join rels in the same way that
other member rels are related to baserels. This can use significantly
more CPU time and memory than regular join planning, because there may
now be a set of "other" rels not only for every base relation but also
for every join relation. In most practical cases, this probably
shouldn't be a problem, because (1) it's probably unusual to join many
tables each with many partitions using the partition keys for all
joins and (2) if you do that scenario then you probably have a big
enough machine to handle the increased memory cost of planning and (3)
the resulting plan is highly likely to be better, so what you spend in
planning you'll make up on the execution side. All the same, for now,
turn this feature off by default.
Currently, we can only perform joins between two tables whose
partitioning schemes are absolutely identical. It would be nice to
cope with other scenarios, such as extra partitions on one side or the
other with no match on the other side, but that will have to wait for
a future patch.
Ashutosh Bapat, reviewed and tested by Rajkumar Raghuwanshi, Amit
Langote, Rafia Sabih, Thomas Munro, Dilip Kumar, Antonin Houska, Amit
Khandekar, and by me. A few final adjustments by me.
Discussion: http://postgr.es/m/CAFjFpRfQ8GrQvzp3jA2wnLqrHmaXna-urjm_UY9BqXj=EaDTSA@mail.gmail.com
Discussion: http://postgr.es/m/CAFjFpRcitjfrULr5jfuKWRPsGUX0LQ0k8-yG0Qw2+1LBGNpMdw@mail.gmail.com
8 years ago
|
|
|
* Builds partition key expressions for the given base relation and sets them
|
|
|
|
|
* in given RelOptInfo. Any single column partition keys are converted to Var
|
|
|
|
|
* nodes. All Var nodes are restamped with the relid of given relation.
|
|
|
|
|
*/
|
Basic partition-wise join functionality.
Instead of joining two partitioned tables in their entirety we can, if
it is an equi-join on the partition keys, join the matching partitions
individually. This involves teaching the planner about "other join"
rels, which are related to regular join rels in the same way that
other member rels are related to baserels. This can use significantly
more CPU time and memory than regular join planning, because there may
now be a set of "other" rels not only for every base relation but also
for every join relation. In most practical cases, this probably
shouldn't be a problem, because (1) it's probably unusual to join many
tables each with many partitions using the partition keys for all
joins and (2) if you do that scenario then you probably have a big
enough machine to handle the increased memory cost of planning and (3)
the resulting plan is highly likely to be better, so what you spend in
planning you'll make up on the execution side. All the same, for now,
turn this feature off by default.
Currently, we can only perform joins between two tables whose
partitioning schemes are absolutely identical. It would be nice to
cope with other scenarios, such as extra partitions on one side or the
other with no match on the other side, but that will have to wait for
a future patch.
Ashutosh Bapat, reviewed and tested by Rajkumar Raghuwanshi, Amit
Langote, Rafia Sabih, Thomas Munro, Dilip Kumar, Antonin Houska, Amit
Khandekar, and by me. A few final adjustments by me.
Discussion: http://postgr.es/m/CAFjFpRfQ8GrQvzp3jA2wnLqrHmaXna-urjm_UY9BqXj=EaDTSA@mail.gmail.com
Discussion: http://postgr.es/m/CAFjFpRcitjfrULr5jfuKWRPsGUX0LQ0k8-yG0Qw2+1LBGNpMdw@mail.gmail.com
8 years ago
|
|
|
static void
|
|
|
|
|
set_baserel_partition_key_exprs(Relation relation,
|
|
|
|
|
RelOptInfo *rel)
|
|
|
|
|
{
|
|
|
|
|
PartitionKey partkey = RelationGetPartitionKey(relation);
|
|
|
|
|
int partnatts;
|
|
|
|
|
int cnt;
|
|
|
|
|
List **partexprs;
|
|
|
|
|
ListCell *lc;
|
Basic partition-wise join functionality.
Instead of joining two partitioned tables in their entirety we can, if
it is an equi-join on the partition keys, join the matching partitions
individually. This involves teaching the planner about "other join"
rels, which are related to regular join rels in the same way that
other member rels are related to baserels. This can use significantly
more CPU time and memory than regular join planning, because there may
now be a set of "other" rels not only for every base relation but also
for every join relation. In most practical cases, this probably
shouldn't be a problem, because (1) it's probably unusual to join many
tables each with many partitions using the partition keys for all
joins and (2) if you do that scenario then you probably have a big
enough machine to handle the increased memory cost of planning and (3)
the resulting plan is highly likely to be better, so what you spend in
planning you'll make up on the execution side. All the same, for now,
turn this feature off by default.
Currently, we can only perform joins between two tables whose
partitioning schemes are absolutely identical. It would be nice to
cope with other scenarios, such as extra partitions on one side or the
other with no match on the other side, but that will have to wait for
a future patch.
Ashutosh Bapat, reviewed and tested by Rajkumar Raghuwanshi, Amit
Langote, Rafia Sabih, Thomas Munro, Dilip Kumar, Antonin Houska, Amit
Khandekar, and by me. A few final adjustments by me.
Discussion: http://postgr.es/m/CAFjFpRfQ8GrQvzp3jA2wnLqrHmaXna-urjm_UY9BqXj=EaDTSA@mail.gmail.com
Discussion: http://postgr.es/m/CAFjFpRcitjfrULr5jfuKWRPsGUX0LQ0k8-yG0Qw2+1LBGNpMdw@mail.gmail.com
8 years ago
|
|
|
Index varno = rel->relid;
|
|
|
|
|
|
|
|
|
|
Assert(IS_SIMPLE_REL(rel) && rel->relid > 0);
|
|
|
|
|
|
|
|
|
|
/* A partitioned table should have a partition key. */
|
|
|
|
|
Assert(partkey != NULL);
|
|
|
|
|
|
|
|
|
|
partnatts = partkey->partnatts;
|
|
|
|
|
partexprs = (List **) palloc(sizeof(List *) * partnatts);
|
|
|
|
|
lc = list_head(partkey->partexprs);
|
|
|
|
|
|
|
|
|
|
for (cnt = 0; cnt < partnatts; cnt++)
|
|
|
|
|
{
|
|
|
|
|
Expr *partexpr;
|
|
|
|
|
AttrNumber attno = partkey->partattrs[cnt];
|
|
|
|
|
|
|
|
|
|
if (attno != InvalidAttrNumber)
|
|
|
|
|
{
|
|
|
|
|
/* Single column partition key is stored as a Var node. */
|
|
|
|
|
Assert(attno > 0);
|
|
|
|
|
|
|
|
|
|
partexpr = (Expr *) makeVar(varno, attno,
|
|
|
|
|
partkey->parttypid[cnt],
|
|
|
|
|
partkey->parttypmod[cnt],
|
|
|
|
|
partkey->parttypcoll[cnt], 0);
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
if (lc == NULL)
|
|
|
|
|
elog(ERROR, "wrong number of partition key expressions");
|
|
|
|
|
|
|
|
|
|
/* Re-stamp the expression with given varno. */
|
|
|
|
|
partexpr = (Expr *) copyObject(lfirst(lc));
|
|
|
|
|
ChangeVarNodes((Node *) partexpr, 1, varno, 0);
|
|
|
|
|
lc = lnext(lc);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
partexprs[cnt] = list_make1(partexpr);
|
|
|
|
|
}
|
|
|
|
|
|
Basic partition-wise join functionality.
Instead of joining two partitioned tables in their entirety we can, if
it is an equi-join on the partition keys, join the matching partitions
individually. This involves teaching the planner about "other join"
rels, which are related to regular join rels in the same way that
other member rels are related to baserels. This can use significantly
more CPU time and memory than regular join planning, because there may
now be a set of "other" rels not only for every base relation but also
for every join relation. In most practical cases, this probably
shouldn't be a problem, because (1) it's probably unusual to join many
tables each with many partitions using the partition keys for all
joins and (2) if you do that scenario then you probably have a big
enough machine to handle the increased memory cost of planning and (3)
the resulting plan is highly likely to be better, so what you spend in
planning you'll make up on the execution side. All the same, for now,
turn this feature off by default.
Currently, we can only perform joins between two tables whose
partitioning schemes are absolutely identical. It would be nice to
cope with other scenarios, such as extra partitions on one side or the
other with no match on the other side, but that will have to wait for
a future patch.
Ashutosh Bapat, reviewed and tested by Rajkumar Raghuwanshi, Amit
Langote, Rafia Sabih, Thomas Munro, Dilip Kumar, Antonin Houska, Amit
Khandekar, and by me. A few final adjustments by me.
Discussion: http://postgr.es/m/CAFjFpRfQ8GrQvzp3jA2wnLqrHmaXna-urjm_UY9BqXj=EaDTSA@mail.gmail.com
Discussion: http://postgr.es/m/CAFjFpRcitjfrULr5jfuKWRPsGUX0LQ0k8-yG0Qw2+1LBGNpMdw@mail.gmail.com
8 years ago
|
|
|
rel->partexprs = partexprs;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* A base relation can not have nullable partition key expressions. We
|
|
|
|
|
* still allocate array of empty expressions lists to keep partition key
|
|
|
|
|
* expression handling code simple. See build_joinrel_partition_info() and
|
|
|
|
|
* match_expr_to_partition_keys().
|
|
|
|
|
*/
|
|
|
|
|
rel->nullable_partexprs = (List **) palloc0(sizeof(List *) * partnatts);
|
|
|
|
|
}
|
