2003-01-11 00:54:24 +01:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
|
|
|
* execGrouping.c
|
|
|
|
* executor utility routines for grouping, hashing, and aggregation
|
|
|
|
*
|
2020-01-01 18:21:45 +01:00
|
|
|
* Portions Copyright (c) 1996-2020, PostgreSQL Global Development Group
|
2003-01-11 00:54:24 +01:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
|
|
|
*
|
|
|
|
*
|
|
|
|
* IDENTIFICATION
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/backend/executor/execGrouping.c
|
2003-01-11 00:54:24 +01:00
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
#include "postgres.h"
|
|
|
|
|
2016-12-16 16:03:08 +01:00
|
|
|
#include "access/parallel.h"
|
2020-02-27 04:55:41 +01:00
|
|
|
#include "common/hashfn.h"
|
2003-01-11 00:54:24 +01:00
|
|
|
#include "executor/executor.h"
|
Install defenses against overflow in BuildTupleHashTable().
The planner can sometimes compute very large values for numGroups, and in
cases where we have no alternative to building a hashtable, such a value
will get fed directly to BuildTupleHashTable as its nbuckets parameter.
There were two ways in which that could go bad. First, BuildTupleHashTable
declared the parameter as "int" but most callers were passing "long"s,
so on 64-bit machines undetected overflow could occur leading to a bogus
negative value. The obvious fix for that is to change the parameter to
"long", which is what I've done in HEAD. In the back branches that seems a
bit risky, though, since third-party code might be calling this function.
So for them, just put in a kluge to treat negative inputs as INT_MAX.
Second, hash_create can go nuts with extremely large requested table sizes
(notably, my_log2 becomes an infinite loop for inputs larger than
LONG_MAX/2). What seems most appropriate to avoid that is to bound the
initial table size request to work_mem.
This fixes bug #6035 reported by Daniel Schreiber. Although the reported
case only occurs back to 8.4 since it involves WITH RECURSIVE, I think
it's a good idea to install the defenses in all supported branches.
2011-05-23 18:52:46 +02:00
|
|
|
#include "miscadmin.h"
|
2019-11-12 04:00:16 +01:00
|
|
|
#include "utils/lsyscache.h"
|
2006-07-11 18:35:33 +02:00
|
|
|
#include "utils/memutils.h"
|
2003-01-11 00:54:24 +01:00
|
|
|
|
2016-10-15 02:22:51 +02:00
|
|
|
static int TupleHashTableMatch(struct tuplehash_hash *tb, const MinimalTuple tuple1, const MinimalTuple tuple2);
|
2020-02-10 19:20:10 +01:00
|
|
|
static uint32 TupleHashTableHash_internal(struct tuplehash_hash *tb,
|
|
|
|
const MinimalTuple tuple);
|
2020-02-29 19:23:12 +01:00
|
|
|
static TupleHashEntry LookupTupleHashEntry_internal(TupleHashTable hashtable,
|
|
|
|
TupleTableSlot *slot,
|
|
|
|
bool *isnew, uint32 hash);
|
2003-01-11 00:54:24 +01:00
|
|
|
|
2016-10-15 02:22:51 +02:00
|
|
|
/*
|
|
|
|
* Define parameters for tuple hash table code generation. The interface is
|
|
|
|
* *also* declared in execnodes.h (to generate the types, which are externally
|
|
|
|
* visible).
|
|
|
|
*/
|
|
|
|
#define SH_PREFIX tuplehash
|
|
|
|
#define SH_ELEMENT_TYPE TupleHashEntryData
|
|
|
|
#define SH_KEY_TYPE MinimalTuple
|
|
|
|
#define SH_KEY firstTuple
|
2020-02-10 19:20:10 +01:00
|
|
|
#define SH_HASH_KEY(tb, key) TupleHashTableHash_internal(tb, key)
|
2016-10-15 02:22:51 +02:00
|
|
|
#define SH_EQUAL(tb, a, b) TupleHashTableMatch(tb, a, b) == 0
|
|
|
|
#define SH_SCOPE extern
|
|
|
|
#define SH_STORE_HASH
|
|
|
|
#define SH_GET_HASH(tb, a) a->hash
|
|
|
|
#define SH_DEFINE
|
|
|
|
#include "lib/simplehash.h"
|
2003-08-19 03:13:41 +02:00
|
|
|
|
|
|
|
|
2003-01-11 00:54:24 +01:00
|
|
|
/*****************************************************************************
|
|
|
|
* Utility routines for grouping tuples together
|
|
|
|
*****************************************************************************/
|
|
|
|
|
2018-02-16 07:39:18 +01:00
|
|
|
/*
|
|
|
|
* execTuplesMatchPrepare
|
2018-02-16 06:55:31 +01:00
|
|
|
* Build expression that can be evaluated using ExecQual(), returning
|
|
|
|
* whether an ExprContext's inner/outer tuples are NOT DISTINCT
|
2018-02-16 07:39:18 +01:00
|
|
|
*/
|
2018-02-16 06:55:31 +01:00
|
|
|
ExprState *
|
|
|
|
execTuplesMatchPrepare(TupleDesc desc,
|
|
|
|
int numCols,
|
2018-12-13 21:17:53 +01:00
|
|
|
const AttrNumber *keyColIdx,
|
|
|
|
const Oid *eqOperators,
|
2019-03-22 12:09:32 +01:00
|
|
|
const Oid *collations,
|
2018-02-16 06:55:31 +01:00
|
|
|
PlanState *parent)
|
2018-02-16 07:39:18 +01:00
|
|
|
{
|
2018-02-16 06:55:31 +01:00
|
|
|
Oid *eqFunctions = (Oid *) palloc(numCols * sizeof(Oid));
|
2018-02-16 07:39:18 +01:00
|
|
|
int i;
|
2018-02-16 06:55:31 +01:00
|
|
|
ExprState *expr;
|
|
|
|
|
|
|
|
if (numCols == 0)
|
|
|
|
return NULL;
|
2003-01-11 00:54:24 +01:00
|
|
|
|
2018-02-16 06:55:31 +01:00
|
|
|
/* lookup equality functions */
|
2003-01-11 00:54:24 +01:00
|
|
|
for (i = 0; i < numCols; i++)
|
2018-02-16 06:55:31 +01:00
|
|
|
eqFunctions[i] = get_opcode(eqOperators[i]);
|
2003-01-11 00:54:24 +01:00
|
|
|
|
2018-02-16 06:55:31 +01:00
|
|
|
/* build actual expression */
|
Introduce notion of different types of slots (without implementing them).
Upcoming work intends to allow pluggable ways to introduce new ways of
storing table data. Accessing those table access methods from the
executor requires TupleTableSlots to be carry tuples in the native
format of such storage methods; otherwise there'll be a significant
conversion overhead.
Different access methods will require different data to store tuples
efficiently (just like virtual, minimal, heap already require fields
in TupleTableSlot). To allow that without requiring additional pointer
indirections, we want to have different structs (embedding
TupleTableSlot) for different types of slots. Thus different types of
slots are needed, which requires adapting creators of slots.
The slot that most efficiently can represent a type of tuple in an
executor node will often depend on the type of slot a child node
uses. Therefore we need to track the type of slot is returned by
nodes, so parent slots can create slots based on that.
Relatedly, JIT compilation of tuple deforming needs to know which type
of slot a certain expression refers to, so it can create an
appropriate deforming function for the type of tuple in the slot.
But not all nodes will only return one type of slot, e.g. an append
node will potentially return different types of slots for each of its
subplans.
Therefore add function that allows to query the type of a node's
result slot, and whether it'll always be the same type (whether it's
fixed). This can be queried using ExecGetResultSlotOps().
The scan, result, inner, outer type of slots are automatically
inferred from ExecInitScanTupleSlot(), ExecInitResultSlot(),
left/right subtrees respectively. If that's not correct for a node,
that can be overwritten using new fields in PlanState.
This commit does not introduce the actually abstracted implementation
of different kind of TupleTableSlots, that will be left for a followup
commit. The different types of slots introduced will, for now, still
use the same backing implementation.
While this already partially invalidates the big comment in
tuptable.h, it seems to make more sense to update it later, when the
different TupleTableSlot implementations actually exist.
Author: Ashutosh Bapat and Andres Freund, with changes by Amit Khandekar
Discussion: https://postgr.es/m/20181105210039.hh4vvi4vwoq5ba2q@alap3.anarazel.de
2018-11-16 07:00:30 +01:00
|
|
|
expr = ExecBuildGroupingEqual(desc, desc, NULL, NULL,
|
2019-03-22 12:09:32 +01:00
|
|
|
numCols, keyColIdx, eqFunctions, collations,
|
2018-02-16 06:55:31 +01:00
|
|
|
parent);
|
2003-01-11 00:54:24 +01:00
|
|
|
|
2018-02-16 06:55:31 +01:00
|
|
|
return expr;
|
2003-01-11 00:54:24 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2003-06-23 00:04:55 +02:00
|
|
|
* execTuplesHashPrepare
|
|
|
|
* Look up the equality and hashing functions needed for a TupleHashTable.
|
2003-01-11 00:54:24 +01:00
|
|
|
*
|
2003-06-23 00:04:55 +02:00
|
|
|
* This is similar to execTuplesMatchPrepare, but we also need to find the
|
2007-01-10 19:06:05 +01:00
|
|
|
* hash functions associated with the equality operators. *eqFunctions and
|
|
|
|
* *hashFunctions receive the palloc'd result arrays.
|
2007-02-06 03:59:15 +01:00
|
|
|
*
|
|
|
|
* Note: we expect that the given operators are not cross-type comparisons.
|
2003-01-11 00:54:24 +01:00
|
|
|
*/
|
2003-06-23 00:04:55 +02:00
|
|
|
void
|
2007-01-10 19:06:05 +01:00
|
|
|
execTuplesHashPrepare(int numCols,
|
2018-12-13 21:17:53 +01:00
|
|
|
const Oid *eqOperators,
|
2018-02-16 06:55:31 +01:00
|
|
|
Oid **eqFuncOids,
|
2007-01-10 19:06:05 +01:00
|
|
|
FmgrInfo **hashFunctions)
|
2003-01-11 00:54:24 +01:00
|
|
|
{
|
2003-06-23 00:04:55 +02:00
|
|
|
int i;
|
2003-01-11 00:54:24 +01:00
|
|
|
|
2018-02-16 06:55:31 +01:00
|
|
|
*eqFuncOids = (Oid *) palloc(numCols * sizeof(Oid));
|
2007-01-10 19:06:05 +01:00
|
|
|
*hashFunctions = (FmgrInfo *) palloc(numCols * sizeof(FmgrInfo));
|
2003-06-23 00:04:55 +02:00
|
|
|
|
|
|
|
for (i = 0; i < numCols; i++)
|
2003-01-11 00:54:24 +01:00
|
|
|
{
|
2007-01-10 19:06:05 +01:00
|
|
|
Oid eq_opr = eqOperators[i];
|
2003-06-23 00:04:55 +02:00
|
|
|
Oid eq_function;
|
2007-01-30 02:33:36 +01:00
|
|
|
Oid left_hash_function;
|
|
|
|
Oid right_hash_function;
|
2003-06-23 00:04:55 +02:00
|
|
|
|
2007-01-10 19:06:05 +01:00
|
|
|
eq_function = get_opcode(eq_opr);
|
2007-01-30 02:33:36 +01:00
|
|
|
if (!get_op_hash_functions(eq_opr,
|
|
|
|
&left_hash_function, &right_hash_function))
|
2003-07-21 19:05:12 +02:00
|
|
|
elog(ERROR, "could not find hash function for hash operator %u",
|
2003-06-23 00:04:55 +02:00
|
|
|
eq_opr);
|
2007-02-06 03:59:15 +01:00
|
|
|
/* We're not supporting cross-type cases here */
|
2007-01-30 02:33:36 +01:00
|
|
|
Assert(left_hash_function == right_hash_function);
|
2018-02-16 06:55:31 +01:00
|
|
|
(*eqFuncOids)[i] = eq_function;
|
2007-01-30 02:33:36 +01:00
|
|
|
fmgr_info(right_hash_function, &(*hashFunctions)[i]);
|
2003-01-11 00:54:24 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*****************************************************************************
|
|
|
|
* Utility routines for all-in-memory hash tables
|
|
|
|
*
|
|
|
|
* These routines build hash tables for grouping tuples together (eg, for
|
|
|
|
* hash aggregation). There is one entry for each not-distinct set of tuples
|
|
|
|
* presented.
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Construct an empty TupleHashTable
|
|
|
|
*
|
|
|
|
* numCols, keyColIdx: identify the tuple fields to use as lookup key
|
|
|
|
* eqfunctions: equality comparison functions to use
|
2003-06-23 00:04:55 +02:00
|
|
|
* hashfunctions: datatype-specific hashing functions to use
|
2003-08-19 03:13:41 +02:00
|
|
|
* nbuckets: initial estimate of hashtable size
|
2016-10-15 02:22:51 +02:00
|
|
|
* additionalsize: size of data stored in ->additional
|
2019-02-09 09:35:57 +01:00
|
|
|
* metacxt: memory context for long-lived allocation, but not per-entry data
|
|
|
|
* tablecxt: memory context in which to store table entries
|
2003-01-11 00:54:24 +01:00
|
|
|
* tempcxt: short-lived context for evaluation hash and comparison functions
|
|
|
|
*
|
2007-02-06 03:59:15 +01:00
|
|
|
* The function arrays may be made with execTuplesHashPrepare(). Note they
|
|
|
|
* are not cross-type functions, but expect to see the table datatype(s)
|
|
|
|
* on both sides.
|
2003-01-11 00:54:24 +01:00
|
|
|
*
|
2003-06-23 00:04:55 +02:00
|
|
|
* Note that keyColIdx, eqfunctions, and hashfunctions must be allocated in
|
|
|
|
* storage that will live as long as the hashtable does.
|
2003-01-11 00:54:24 +01:00
|
|
|
*/
|
|
|
|
TupleHashTable
|
2019-02-09 09:35:57 +01:00
|
|
|
BuildTupleHashTableExt(PlanState *parent,
|
|
|
|
TupleDesc inputDesc,
|
|
|
|
int numCols, AttrNumber *keyColIdx,
|
|
|
|
const Oid *eqfuncoids,
|
|
|
|
FmgrInfo *hashfunctions,
|
2019-03-22 12:09:32 +01:00
|
|
|
Oid *collations,
|
2019-02-09 09:35:57 +01:00
|
|
|
long nbuckets, Size additionalsize,
|
|
|
|
MemoryContext metacxt,
|
|
|
|
MemoryContext tablecxt,
|
|
|
|
MemoryContext tempcxt,
|
|
|
|
bool use_variable_hash_iv)
|
2003-01-11 00:54:24 +01:00
|
|
|
{
|
2003-08-04 02:43:34 +02:00
|
|
|
TupleHashTable hashtable;
|
2016-10-15 02:22:51 +02:00
|
|
|
Size entrysize = sizeof(TupleHashEntryData) + additionalsize;
|
2018-02-16 06:55:31 +01:00
|
|
|
MemoryContext oldcontext;
|
jit: Re-allow JIT compilation of execGrouping.c hashtable comparisons.
In the course of 5567d12ce03, 356687bd8 and 317ffdfeaac, I changed
BuildTupleHashTable[Ext]'s call to ExecBuildGroupingEqual to not pass
in the parent node, but NULL. Which in turn prevents the tuple
equality comparator from being JIT compiled. While that fixes
bug #15486, it is not actually necessary after all of the above commits,
as we don't re-build the comparator when using the new
BuildTupleHashTableExt() interface (as the content of the hashtable
are reset, but the TupleHashTable itself is not).
Therefore re-allow jit compilation for callers that use
BuildTupleHashTableExt with a separate context for "metadata" and
content.
As in the previous commit, there's ongoing work to make this easier to
test to prevent such regressions in the future, but that
infrastructure is not going to be backpatchable.
The performance impact of not JIT compiling hashtable equality
comparators can be substantial e.g. for aggregation queries that
aggregate a lot of input rows to few output rows (when there are a lot
of output groups, there will be fewer comparisons).
Author: Andres Freund
Discussion: https://postgr.es/m/20190927072053.njf6prdl3vb7y7qb@alap3.anarazel.de
Backpatch: 11, just as 5567d12ce03
2019-09-30 01:24:32 +02:00
|
|
|
bool allow_jit;
|
2003-01-11 00:54:24 +01:00
|
|
|
|
|
|
|
Assert(nbuckets > 0);
|
|
|
|
|
Install defenses against overflow in BuildTupleHashTable().
The planner can sometimes compute very large values for numGroups, and in
cases where we have no alternative to building a hashtable, such a value
will get fed directly to BuildTupleHashTable as its nbuckets parameter.
There were two ways in which that could go bad. First, BuildTupleHashTable
declared the parameter as "int" but most callers were passing "long"s,
so on 64-bit machines undetected overflow could occur leading to a bogus
negative value. The obvious fix for that is to change the parameter to
"long", which is what I've done in HEAD. In the back branches that seems a
bit risky, though, since third-party code might be calling this function.
So for them, just put in a kluge to treat negative inputs as INT_MAX.
Second, hash_create can go nuts with extremely large requested table sizes
(notably, my_log2 becomes an infinite loop for inputs larger than
LONG_MAX/2). What seems most appropriate to avoid that is to bound the
initial table size request to work_mem.
This fixes bug #6035 reported by Daniel Schreiber. Although the reported
case only occurs back to 8.4 since it involves WITH RECURSIVE, I think
it's a good idea to install the defenses in all supported branches.
2011-05-23 18:52:46 +02:00
|
|
|
/* Limit initial table size request to not more than work_mem */
|
|
|
|
nbuckets = Min(nbuckets, (long) ((work_mem * 1024L) / entrysize));
|
|
|
|
|
2019-02-09 09:35:57 +01:00
|
|
|
oldcontext = MemoryContextSwitchTo(metacxt);
|
|
|
|
|
|
|
|
hashtable = (TupleHashTable) palloc(sizeof(TupleHashTableData));
|
2003-01-11 00:54:24 +01:00
|
|
|
|
|
|
|
hashtable->numCols = numCols;
|
|
|
|
hashtable->keyColIdx = keyColIdx;
|
2007-02-06 03:59:15 +01:00
|
|
|
hashtable->tab_hash_funcs = hashfunctions;
|
2019-03-22 12:09:32 +01:00
|
|
|
hashtable->tab_collations = collations;
|
2003-01-11 00:54:24 +01:00
|
|
|
hashtable->tablecxt = tablecxt;
|
|
|
|
hashtable->tempcxt = tempcxt;
|
|
|
|
hashtable->entrysize = entrysize;
|
2005-10-15 04:49:52 +02:00
|
|
|
hashtable->tableslot = NULL; /* will be made on first lookup */
|
2005-03-16 22:38:10 +01:00
|
|
|
hashtable->inputslot = NULL;
|
2007-02-06 03:59:15 +01:00
|
|
|
hashtable->in_hash_funcs = NULL;
|
2018-02-16 06:55:31 +01:00
|
|
|
hashtable->cur_eq_func = NULL;
|
2003-08-19 03:13:41 +02:00
|
|
|
|
2016-12-16 16:03:08 +01:00
|
|
|
/*
|
|
|
|
* If parallelism is in use, even if the master backend is performing the
|
|
|
|
* scan itself, we don't want to create the hashtable exactly the same way
|
|
|
|
* in all workers. As hashtables are iterated over in keyspace-order,
|
|
|
|
* doing so in all processes in the same way is likely to lead to
|
|
|
|
* "unbalanced" hashtables when the table size initially is
|
|
|
|
* underestimated.
|
|
|
|
*/
|
|
|
|
if (use_variable_hash_iv)
|
2018-01-29 20:02:09 +01:00
|
|
|
hashtable->hash_iv = murmurhash32(ParallelWorkerNumber);
|
2016-12-16 16:03:08 +01:00
|
|
|
else
|
|
|
|
hashtable->hash_iv = 0;
|
|
|
|
|
2019-02-09 09:35:57 +01:00
|
|
|
hashtable->hashtab = tuplehash_create(metacxt, nbuckets, hashtable);
|
2018-02-16 06:55:31 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* We copy the input tuple descriptor just for safety --- we assume all
|
|
|
|
* input tuples will have equivalent descriptors.
|
|
|
|
*/
|
Introduce notion of different types of slots (without implementing them).
Upcoming work intends to allow pluggable ways to introduce new ways of
storing table data. Accessing those table access methods from the
executor requires TupleTableSlots to be carry tuples in the native
format of such storage methods; otherwise there'll be a significant
conversion overhead.
Different access methods will require different data to store tuples
efficiently (just like virtual, minimal, heap already require fields
in TupleTableSlot). To allow that without requiring additional pointer
indirections, we want to have different structs (embedding
TupleTableSlot) for different types of slots. Thus different types of
slots are needed, which requires adapting creators of slots.
The slot that most efficiently can represent a type of tuple in an
executor node will often depend on the type of slot a child node
uses. Therefore we need to track the type of slot is returned by
nodes, so parent slots can create slots based on that.
Relatedly, JIT compilation of tuple deforming needs to know which type
of slot a certain expression refers to, so it can create an
appropriate deforming function for the type of tuple in the slot.
But not all nodes will only return one type of slot, e.g. an append
node will potentially return different types of slots for each of its
subplans.
Therefore add function that allows to query the type of a node's
result slot, and whether it'll always be the same type (whether it's
fixed). This can be queried using ExecGetResultSlotOps().
The scan, result, inner, outer type of slots are automatically
inferred from ExecInitScanTupleSlot(), ExecInitResultSlot(),
left/right subtrees respectively. If that's not correct for a node,
that can be overwritten using new fields in PlanState.
This commit does not introduce the actually abstracted implementation
of different kind of TupleTableSlots, that will be left for a followup
commit. The different types of slots introduced will, for now, still
use the same backing implementation.
While this already partially invalidates the big comment in
tuptable.h, it seems to make more sense to update it later, when the
different TupleTableSlot implementations actually exist.
Author: Ashutosh Bapat and Andres Freund, with changes by Amit Khandekar
Discussion: https://postgr.es/m/20181105210039.hh4vvi4vwoq5ba2q@alap3.anarazel.de
2018-11-16 07:00:30 +01:00
|
|
|
hashtable->tableslot = MakeSingleTupleTableSlot(CreateTupleDescCopy(inputDesc),
|
|
|
|
&TTSOpsMinimalTuple);
|
2018-02-16 06:55:31 +01:00
|
|
|
|
jit: Re-allow JIT compilation of execGrouping.c hashtable comparisons.
In the course of 5567d12ce03, 356687bd8 and 317ffdfeaac, I changed
BuildTupleHashTable[Ext]'s call to ExecBuildGroupingEqual to not pass
in the parent node, but NULL. Which in turn prevents the tuple
equality comparator from being JIT compiled. While that fixes
bug #15486, it is not actually necessary after all of the above commits,
as we don't re-build the comparator when using the new
BuildTupleHashTableExt() interface (as the content of the hashtable
are reset, but the TupleHashTable itself is not).
Therefore re-allow jit compilation for callers that use
BuildTupleHashTableExt with a separate context for "metadata" and
content.
As in the previous commit, there's ongoing work to make this easier to
test to prevent such regressions in the future, but that
infrastructure is not going to be backpatchable.
The performance impact of not JIT compiling hashtable equality
comparators can be substantial e.g. for aggregation queries that
aggregate a lot of input rows to few output rows (when there are a lot
of output groups, there will be fewer comparisons).
Author: Andres Freund
Discussion: https://postgr.es/m/20190927072053.njf6prdl3vb7y7qb@alap3.anarazel.de
Backpatch: 11, just as 5567d12ce03
2019-09-30 01:24:32 +02:00
|
|
|
/*
|
|
|
|
* If the old reset interface is used (i.e. BuildTupleHashTable, rather
|
|
|
|
* than BuildTupleHashTableExt), allowing JIT would lead to the generated
|
|
|
|
* functions to a) live longer than the query b) be re-generated each time
|
|
|
|
* the table is being reset. Therefore prevent JIT from being used in that
|
|
|
|
* case, by not providing a parent node (which prevents accessing the
|
|
|
|
* JitContext in the EState).
|
|
|
|
*/
|
|
|
|
allow_jit = metacxt != tablecxt;
|
|
|
|
|
2018-02-16 06:55:31 +01:00
|
|
|
/* build comparator for all columns */
|
Introduce notion of different types of slots (without implementing them).
Upcoming work intends to allow pluggable ways to introduce new ways of
storing table data. Accessing those table access methods from the
executor requires TupleTableSlots to be carry tuples in the native
format of such storage methods; otherwise there'll be a significant
conversion overhead.
Different access methods will require different data to store tuples
efficiently (just like virtual, minimal, heap already require fields
in TupleTableSlot). To allow that without requiring additional pointer
indirections, we want to have different structs (embedding
TupleTableSlot) for different types of slots. Thus different types of
slots are needed, which requires adapting creators of slots.
The slot that most efficiently can represent a type of tuple in an
executor node will often depend on the type of slot a child node
uses. Therefore we need to track the type of slot is returned by
nodes, so parent slots can create slots based on that.
Relatedly, JIT compilation of tuple deforming needs to know which type
of slot a certain expression refers to, so it can create an
appropriate deforming function for the type of tuple in the slot.
But not all nodes will only return one type of slot, e.g. an append
node will potentially return different types of slots for each of its
subplans.
Therefore add function that allows to query the type of a node's
result slot, and whether it'll always be the same type (whether it's
fixed). This can be queried using ExecGetResultSlotOps().
The scan, result, inner, outer type of slots are automatically
inferred from ExecInitScanTupleSlot(), ExecInitResultSlot(),
left/right subtrees respectively. If that's not correct for a node,
that can be overwritten using new fields in PlanState.
This commit does not introduce the actually abstracted implementation
of different kind of TupleTableSlots, that will be left for a followup
commit. The different types of slots introduced will, for now, still
use the same backing implementation.
While this already partially invalidates the big comment in
tuptable.h, it seems to make more sense to update it later, when the
different TupleTableSlot implementations actually exist.
Author: Ashutosh Bapat and Andres Freund, with changes by Amit Khandekar
Discussion: https://postgr.es/m/20181105210039.hh4vvi4vwoq5ba2q@alap3.anarazel.de
2018-11-16 07:00:30 +01:00
|
|
|
/* XXX: should we support non-minimal tuples for the inputslot? */
|
2018-02-16 06:55:31 +01:00
|
|
|
hashtable->tab_eq_func = ExecBuildGroupingEqual(inputDesc, inputDesc,
|
Introduce notion of different types of slots (without implementing them).
Upcoming work intends to allow pluggable ways to introduce new ways of
storing table data. Accessing those table access methods from the
executor requires TupleTableSlots to be carry tuples in the native
format of such storage methods; otherwise there'll be a significant
conversion overhead.
Different access methods will require different data to store tuples
efficiently (just like virtual, minimal, heap already require fields
in TupleTableSlot). To allow that without requiring additional pointer
indirections, we want to have different structs (embedding
TupleTableSlot) for different types of slots. Thus different types of
slots are needed, which requires adapting creators of slots.
The slot that most efficiently can represent a type of tuple in an
executor node will often depend on the type of slot a child node
uses. Therefore we need to track the type of slot is returned by
nodes, so parent slots can create slots based on that.
Relatedly, JIT compilation of tuple deforming needs to know which type
of slot a certain expression refers to, so it can create an
appropriate deforming function for the type of tuple in the slot.
But not all nodes will only return one type of slot, e.g. an append
node will potentially return different types of slots for each of its
subplans.
Therefore add function that allows to query the type of a node's
result slot, and whether it'll always be the same type (whether it's
fixed). This can be queried using ExecGetResultSlotOps().
The scan, result, inner, outer type of slots are automatically
inferred from ExecInitScanTupleSlot(), ExecInitResultSlot(),
left/right subtrees respectively. If that's not correct for a node,
that can be overwritten using new fields in PlanState.
This commit does not introduce the actually abstracted implementation
of different kind of TupleTableSlots, that will be left for a followup
commit. The different types of slots introduced will, for now, still
use the same backing implementation.
While this already partially invalidates the big comment in
tuptable.h, it seems to make more sense to update it later, when the
different TupleTableSlot implementations actually exist.
Author: Ashutosh Bapat and Andres Freund, with changes by Amit Khandekar
Discussion: https://postgr.es/m/20181105210039.hh4vvi4vwoq5ba2q@alap3.anarazel.de
2018-11-16 07:00:30 +01:00
|
|
|
&TTSOpsMinimalTuple, &TTSOpsMinimalTuple,
|
2018-02-16 06:55:31 +01:00
|
|
|
numCols,
|
2019-03-22 12:09:32 +01:00
|
|
|
keyColIdx, eqfuncoids, collations,
|
jit: Re-allow JIT compilation of execGrouping.c hashtable comparisons.
In the course of 5567d12ce03, 356687bd8 and 317ffdfeaac, I changed
BuildTupleHashTable[Ext]'s call to ExecBuildGroupingEqual to not pass
in the parent node, but NULL. Which in turn prevents the tuple
equality comparator from being JIT compiled. While that fixes
bug #15486, it is not actually necessary after all of the above commits,
as we don't re-build the comparator when using the new
BuildTupleHashTableExt() interface (as the content of the hashtable
are reset, but the TupleHashTable itself is not).
Therefore re-allow jit compilation for callers that use
BuildTupleHashTableExt with a separate context for "metadata" and
content.
As in the previous commit, there's ongoing work to make this easier to
test to prevent such regressions in the future, but that
infrastructure is not going to be backpatchable.
The performance impact of not JIT compiling hashtable equality
comparators can be substantial e.g. for aggregation queries that
aggregate a lot of input rows to few output rows (when there are a lot
of output groups, there will be fewer comparisons).
Author: Andres Freund
Discussion: https://postgr.es/m/20190927072053.njf6prdl3vb7y7qb@alap3.anarazel.de
Backpatch: 11, just as 5567d12ce03
2019-09-30 01:24:32 +02:00
|
|
|
allow_jit ? parent : NULL);
|
2018-02-16 06:55:31 +01:00
|
|
|
|
2019-02-09 09:35:57 +01:00
|
|
|
/*
|
|
|
|
* While not pretty, it's ok to not shut down this context, but instead
|
|
|
|
* rely on the containing memory context being reset, as
|
|
|
|
* ExecBuildGroupingEqual() only builds a very simple expression calling
|
|
|
|
* functions (i.e. nothing that'd employ RegisterExprContextCallback()).
|
|
|
|
*/
|
|
|
|
hashtable->exprcontext = CreateStandaloneExprContext();
|
2018-02-16 06:55:31 +01:00
|
|
|
|
2019-02-09 09:35:57 +01:00
|
|
|
MemoryContextSwitchTo(oldcontext);
|
2018-02-16 06:55:31 +01:00
|
|
|
|
2003-01-11 00:54:24 +01:00
|
|
|
return hashtable;
|
|
|
|
}
|
|
|
|
|
2019-02-09 09:35:57 +01:00
|
|
|
/*
|
|
|
|
* BuildTupleHashTable is a backwards-compatibilty wrapper for
|
|
|
|
* BuildTupleHashTableExt(), that allocates the hashtable's metadata in
|
|
|
|
* tablecxt. Note that hashtables created this way cannot be reset leak-free
|
|
|
|
* with ResetTupleHashTable().
|
|
|
|
*/
|
|
|
|
TupleHashTable
|
|
|
|
BuildTupleHashTable(PlanState *parent,
|
|
|
|
TupleDesc inputDesc,
|
|
|
|
int numCols, AttrNumber *keyColIdx,
|
|
|
|
const Oid *eqfuncoids,
|
|
|
|
FmgrInfo *hashfunctions,
|
2019-03-22 12:09:32 +01:00
|
|
|
Oid *collations,
|
2019-02-09 09:35:57 +01:00
|
|
|
long nbuckets, Size additionalsize,
|
|
|
|
MemoryContext tablecxt,
|
|
|
|
MemoryContext tempcxt,
|
|
|
|
bool use_variable_hash_iv)
|
|
|
|
{
|
|
|
|
return BuildTupleHashTableExt(parent,
|
|
|
|
inputDesc,
|
|
|
|
numCols, keyColIdx,
|
|
|
|
eqfuncoids,
|
|
|
|
hashfunctions,
|
2019-03-22 12:09:32 +01:00
|
|
|
collations,
|
2019-02-09 09:35:57 +01:00
|
|
|
nbuckets, additionalsize,
|
|
|
|
tablecxt,
|
|
|
|
tablecxt,
|
|
|
|
tempcxt,
|
|
|
|
use_variable_hash_iv);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Reset contents of the hashtable to be empty, preserving all the non-content
|
|
|
|
* state. Note that the tablecxt passed to BuildTupleHashTableExt() should
|
|
|
|
* also be reset, otherwise there will be leaks.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
ResetTupleHashTable(TupleHashTable hashtable)
|
|
|
|
{
|
|
|
|
tuplehash_reset(hashtable->hashtab);
|
|
|
|
}
|
|
|
|
|
2003-01-11 00:54:24 +01:00
|
|
|
/*
|
|
|
|
* Find or create a hashtable entry for the tuple group containing the
|
2007-02-06 03:59:15 +01:00
|
|
|
* given tuple. The tuple must be the same type as the hashtable entries.
|
2003-01-11 00:54:24 +01:00
|
|
|
*
|
2003-01-12 05:03:34 +01:00
|
|
|
* If isnew is NULL, we do not create new entries; we return NULL if no
|
|
|
|
* match is found.
|
|
|
|
*
|
|
|
|
* If isnew isn't NULL, then a new entry is created if no existing entry
|
|
|
|
* matches. On return, *isnew is true if the entry is newly created,
|
2016-10-15 02:22:51 +02:00
|
|
|
* false if it existed already. ->additional_data in the new entry has
|
|
|
|
* been zeroed.
|
2003-01-11 00:54:24 +01:00
|
|
|
*/
|
|
|
|
TupleHashEntry
|
|
|
|
LookupTupleHashEntry(TupleHashTable hashtable, TupleTableSlot *slot,
|
|
|
|
bool *isnew)
|
|
|
|
{
|
2020-05-14 19:06:38 +02:00
|
|
|
TupleHashEntry entry;
|
|
|
|
MemoryContext oldContext;
|
|
|
|
uint32 hash;
|
2003-01-11 00:54:24 +01:00
|
|
|
|
2003-08-19 03:13:41 +02:00
|
|
|
/* Need to run the hash functions in short-lived context */
|
2003-01-11 00:54:24 +01:00
|
|
|
oldContext = MemoryContextSwitchTo(hashtable->tempcxt);
|
|
|
|
|
2016-10-15 02:22:51 +02:00
|
|
|
/* set up data needed by hash and match functions */
|
2005-03-16 22:38:10 +01:00
|
|
|
hashtable->inputslot = slot;
|
2007-02-06 03:59:15 +01:00
|
|
|
hashtable->in_hash_funcs = hashtable->tab_hash_funcs;
|
2018-02-16 06:55:31 +01:00
|
|
|
hashtable->cur_eq_func = hashtable->tab_eq_func;
|
2007-02-06 03:59:15 +01:00
|
|
|
|
2020-02-10 19:20:10 +01:00
|
|
|
hash = TupleHashTableHash_internal(hashtable->hashtab, NULL);
|
2020-02-07 04:39:47 +01:00
|
|
|
entry = LookupTupleHashEntry_internal(hashtable, slot, isnew, hash);
|
2003-08-19 03:13:41 +02:00
|
|
|
|
2020-02-07 04:39:47 +01:00
|
|
|
MemoryContextSwitchTo(oldContext);
|
2016-10-15 02:22:51 +02:00
|
|
|
|
2020-02-07 04:39:47 +01:00
|
|
|
return entry;
|
|
|
|
}
|
|
|
|
|
2020-02-10 19:20:10 +01:00
|
|
|
/*
|
|
|
|
* Compute the hash value for a tuple
|
|
|
|
*/
|
|
|
|
uint32
|
|
|
|
TupleHashTableHash(TupleHashTable hashtable, TupleTableSlot *slot)
|
|
|
|
{
|
2020-05-14 19:06:38 +02:00
|
|
|
MemoryContext oldContext;
|
|
|
|
uint32 hash;
|
2020-02-10 19:20:10 +01:00
|
|
|
|
|
|
|
hashtable->inputslot = slot;
|
|
|
|
hashtable->in_hash_funcs = hashtable->tab_hash_funcs;
|
|
|
|
|
|
|
|
/* Need to run the hash functions in short-lived context */
|
|
|
|
oldContext = MemoryContextSwitchTo(hashtable->tempcxt);
|
|
|
|
|
|
|
|
hash = TupleHashTableHash_internal(hashtable->hashtab, NULL);
|
|
|
|
|
|
|
|
MemoryContextSwitchTo(oldContext);
|
|
|
|
|
|
|
|
return hash;
|
|
|
|
}
|
|
|
|
|
2020-02-07 04:39:47 +01:00
|
|
|
/*
|
|
|
|
* A variant of LookupTupleHashEntry for callers that have already computed
|
|
|
|
* the hash value.
|
|
|
|
*/
|
|
|
|
TupleHashEntry
|
|
|
|
LookupTupleHashEntryHash(TupleHashTable hashtable, TupleTableSlot *slot,
|
|
|
|
bool *isnew, uint32 hash)
|
|
|
|
{
|
2020-05-14 19:06:38 +02:00
|
|
|
TupleHashEntry entry;
|
|
|
|
MemoryContext oldContext;
|
2020-02-07 04:39:47 +01:00
|
|
|
|
|
|
|
/* Need to run the hash functions in short-lived context */
|
|
|
|
oldContext = MemoryContextSwitchTo(hashtable->tempcxt);
|
|
|
|
|
|
|
|
/* set up data needed by hash and match functions */
|
|
|
|
hashtable->inputslot = slot;
|
|
|
|
hashtable->in_hash_funcs = hashtable->tab_hash_funcs;
|
|
|
|
hashtable->cur_eq_func = hashtable->tab_eq_func;
|
|
|
|
|
|
|
|
entry = LookupTupleHashEntry_internal(hashtable, slot, isnew, hash);
|
2003-08-19 03:13:41 +02:00
|
|
|
|
|
|
|
MemoryContextSwitchTo(oldContext);
|
|
|
|
|
|
|
|
return entry;
|
|
|
|
}
|
|
|
|
|
2007-02-06 03:59:15 +01:00
|
|
|
/*
|
|
|
|
* Search for a hashtable entry matching the given tuple. No entry is
|
|
|
|
* created if there's not a match. This is similar to the non-creating
|
|
|
|
* case of LookupTupleHashEntry, except that it supports cross-type
|
|
|
|
* comparisons, in which the given tuple is not of the same type as the
|
|
|
|
* table entries. The caller must provide the hash functions to use for
|
|
|
|
* the input tuple, as well as the equality functions, since these may be
|
|
|
|
* different from the table's internal functions.
|
|
|
|
*/
|
|
|
|
TupleHashEntry
|
|
|
|
FindTupleHashEntry(TupleHashTable hashtable, TupleTableSlot *slot,
|
2018-02-16 06:55:31 +01:00
|
|
|
ExprState *eqcomp,
|
2007-02-06 03:59:15 +01:00
|
|
|
FmgrInfo *hashfunctions)
|
|
|
|
{
|
|
|
|
TupleHashEntry entry;
|
|
|
|
MemoryContext oldContext;
|
2016-10-15 02:22:51 +02:00
|
|
|
MinimalTuple key;
|
2007-02-06 03:59:15 +01:00
|
|
|
|
|
|
|
/* Need to run the hash functions in short-lived context */
|
|
|
|
oldContext = MemoryContextSwitchTo(hashtable->tempcxt);
|
|
|
|
|
2016-10-15 02:22:51 +02:00
|
|
|
/* Set up data needed by hash and match functions */
|
2007-02-06 03:59:15 +01:00
|
|
|
hashtable->inputslot = slot;
|
|
|
|
hashtable->in_hash_funcs = hashfunctions;
|
2018-02-16 06:55:31 +01:00
|
|
|
hashtable->cur_eq_func = eqcomp;
|
2007-02-06 03:59:15 +01:00
|
|
|
|
|
|
|
/* Search the hash table */
|
2016-10-15 02:22:51 +02:00
|
|
|
key = NULL; /* flag to reference inputslot */
|
|
|
|
entry = tuplehash_lookup(hashtable->hashtab, key);
|
2007-02-06 03:59:15 +01:00
|
|
|
MemoryContextSwitchTo(oldContext);
|
|
|
|
|
|
|
|
return entry;
|
|
|
|
}
|
|
|
|
|
2003-08-19 03:13:41 +02:00
|
|
|
/*
|
2019-12-06 20:47:59 +01:00
|
|
|
* If tuple is NULL, use the input slot instead. This convention avoids the
|
|
|
|
* need to materialize virtual input tuples unless they actually need to get
|
|
|
|
* copied into the table.
|
2003-08-19 03:13:41 +02:00
|
|
|
*
|
|
|
|
* Also, the caller must select an appropriate memory context for running
|
2006-06-28 19:05:49 +02:00
|
|
|
* the hash functions. (dynahash.c doesn't change CurrentMemoryContext.)
|
2003-08-19 03:13:41 +02:00
|
|
|
*/
|
2020-02-10 19:20:10 +01:00
|
|
|
static uint32
|
|
|
|
TupleHashTableHash_internal(struct tuplehash_hash *tb,
|
|
|
|
const MinimalTuple tuple)
|
2003-08-19 03:13:41 +02:00
|
|
|
{
|
2016-10-26 18:00:00 +02:00
|
|
|
TupleHashTable hashtable = (TupleHashTable) tb->private_data;
|
2003-08-19 03:13:41 +02:00
|
|
|
int numCols = hashtable->numCols;
|
|
|
|
AttrNumber *keyColIdx = hashtable->keyColIdx;
|
2016-12-16 16:03:08 +01:00
|
|
|
uint32 hashkey = hashtable->hash_iv;
|
2016-10-15 02:22:51 +02:00
|
|
|
TupleTableSlot *slot;
|
|
|
|
FmgrInfo *hashfunctions;
|
2003-08-19 03:13:41 +02:00
|
|
|
int i;
|
|
|
|
|
2005-03-16 22:38:10 +01:00
|
|
|
if (tuple == NULL)
|
|
|
|
{
|
|
|
|
/* Process the current input tuple for the table */
|
|
|
|
slot = hashtable->inputslot;
|
2007-02-06 03:59:15 +01:00
|
|
|
hashfunctions = hashtable->in_hash_funcs;
|
2005-03-16 22:38:10 +01:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2016-10-15 02:22:51 +02:00
|
|
|
/*
|
|
|
|
* Process a tuple already stored in the table.
|
|
|
|
*
|
|
|
|
* (this case never actually occurs due to the way simplehash.h is
|
|
|
|
* used, as the hash-value is stored in the entries)
|
|
|
|
*/
|
2005-03-16 22:38:10 +01:00
|
|
|
slot = hashtable->tableslot;
|
2006-06-28 19:05:49 +02:00
|
|
|
ExecStoreMinimalTuple(tuple, slot, false);
|
2007-02-06 03:59:15 +01:00
|
|
|
hashfunctions = hashtable->tab_hash_funcs;
|
2005-03-16 22:38:10 +01:00
|
|
|
}
|
|
|
|
|
2003-01-11 00:54:24 +01:00
|
|
|
for (i = 0; i < numCols; i++)
|
|
|
|
{
|
|
|
|
AttrNumber att = keyColIdx[i];
|
|
|
|
Datum attr;
|
|
|
|
bool isNull;
|
|
|
|
|
|
|
|
/* rotate hashkey left 1 bit at each step */
|
|
|
|
hashkey = (hashkey << 1) | ((hashkey & 0x80000000) ? 1 : 0);
|
|
|
|
|
2005-03-16 22:38:10 +01:00
|
|
|
attr = slot_getattr(slot, att, &isNull);
|
2003-06-23 00:04:55 +02:00
|
|
|
|
|
|
|
if (!isNull) /* treat nulls as having hash key 0 */
|
|
|
|
{
|
|
|
|
uint32 hkey;
|
|
|
|
|
2019-03-22 12:09:32 +01:00
|
|
|
hkey = DatumGetUInt32(FunctionCall1Coll(&hashfunctions[i],
|
|
|
|
hashtable->tab_collations[i],
|
|
|
|
attr));
|
2003-06-23 00:04:55 +02:00
|
|
|
hashkey ^= hkey;
|
|
|
|
}
|
2003-01-11 00:54:24 +01:00
|
|
|
}
|
|
|
|
|
2018-01-29 20:02:09 +01:00
|
|
|
/*
|
|
|
|
* The way hashes are combined above, among each other and with the IV,
|
|
|
|
* doesn't lead to good bit perturbation. As the IV's goal is to lead to
|
|
|
|
* achieve that, perform a round of hashing of the combined hash -
|
|
|
|
* resulting in near perfect perturbation.
|
|
|
|
*/
|
|
|
|
return murmurhash32(hashkey);
|
2003-01-11 00:54:24 +01:00
|
|
|
}
|
|
|
|
|
2020-02-07 04:39:47 +01:00
|
|
|
/*
|
|
|
|
* Does the work of LookupTupleHashEntry and LookupTupleHashEntryHash. Useful
|
|
|
|
* so that we can avoid switching the memory context multiple times for
|
|
|
|
* LookupTupleHashEntry.
|
|
|
|
*
|
|
|
|
* NB: This function may or may not change the memory context. Caller is
|
|
|
|
* expected to change it back.
|
|
|
|
*/
|
|
|
|
static TupleHashEntry
|
|
|
|
LookupTupleHashEntry_internal(TupleHashTable hashtable, TupleTableSlot *slot,
|
|
|
|
bool *isnew, uint32 hash)
|
|
|
|
{
|
|
|
|
TupleHashEntryData *entry;
|
|
|
|
bool found;
|
|
|
|
MinimalTuple key;
|
|
|
|
|
|
|
|
key = NULL; /* flag to reference inputslot */
|
|
|
|
|
|
|
|
if (isnew)
|
|
|
|
{
|
|
|
|
entry = tuplehash_insert_hash(hashtable->hashtab, key, hash, &found);
|
|
|
|
|
|
|
|
if (found)
|
|
|
|
{
|
|
|
|
/* found pre-existing entry */
|
|
|
|
*isnew = false;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* created new entry */
|
|
|
|
*isnew = true;
|
|
|
|
/* zero caller data */
|
|
|
|
entry->additional = NULL;
|
|
|
|
MemoryContextSwitchTo(hashtable->tablecxt);
|
|
|
|
/* Copy the first tuple into the table context */
|
|
|
|
entry->firstTuple = ExecCopySlotMinimalTuple(slot);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
entry = tuplehash_lookup_hash(hashtable->hashtab, key, hash);
|
|
|
|
}
|
|
|
|
|
|
|
|
return entry;
|
|
|
|
}
|
|
|
|
|
2003-01-11 00:54:24 +01:00
|
|
|
/*
|
2003-08-19 03:13:41 +02:00
|
|
|
* See whether two tuples (presumably of the same hash value) match
|
2003-01-11 00:54:24 +01:00
|
|
|
*/
|
2003-08-19 03:13:41 +02:00
|
|
|
static int
|
2016-10-15 02:22:51 +02:00
|
|
|
TupleHashTableMatch(struct tuplehash_hash *tb, const MinimalTuple tuple1, const MinimalTuple tuple2)
|
2003-01-11 00:54:24 +01:00
|
|
|
{
|
2005-03-16 22:38:10 +01:00
|
|
|
TupleTableSlot *slot1;
|
|
|
|
TupleTableSlot *slot2;
|
2016-10-26 18:00:00 +02:00
|
|
|
TupleHashTable hashtable = (TupleHashTable) tb->private_data;
|
2018-02-16 06:55:31 +01:00
|
|
|
ExprContext *econtext = hashtable->exprcontext;
|
2003-08-19 03:13:41 +02:00
|
|
|
|
2005-03-16 22:38:10 +01:00
|
|
|
/*
|
2016-10-15 02:22:51 +02:00
|
|
|
* We assume that simplehash.h will only ever call us with the first
|
2005-03-16 22:38:10 +01:00
|
|
|
* argument being an actual table entry, and the second argument being
|
|
|
|
* LookupTupleHashEntry's dummy TupleHashEntryData. The other direction
|
2016-10-15 02:22:51 +02:00
|
|
|
* could be supported too, but is not currently required.
|
2005-03-16 22:38:10 +01:00
|
|
|
*/
|
|
|
|
Assert(tuple1 != NULL);
|
|
|
|
slot1 = hashtable->tableslot;
|
2006-06-28 19:05:49 +02:00
|
|
|
ExecStoreMinimalTuple(tuple1, slot1, false);
|
2005-03-16 22:38:10 +01:00
|
|
|
Assert(tuple2 == NULL);
|
|
|
|
slot2 = hashtable->inputslot;
|
|
|
|
|
2007-02-06 03:59:15 +01:00
|
|
|
/* For crosstype comparisons, the inputslot must be first */
|
2018-02-16 06:55:31 +01:00
|
|
|
econtext->ecxt_innertuple = slot2;
|
|
|
|
econtext->ecxt_outertuple = slot1;
|
|
|
|
return !ExecQualAndReset(hashtable->cur_eq_func, econtext);
|
2003-01-11 00:54:24 +01:00
|
|
|
}
|