postgresql/contrib/intarray/_int_gist.c

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

614 lines
14 KiB
C
Raw Normal View History

/*
2010-09-20 22:08:53 +02:00
* contrib/intarray/_int_gist.c
*/
#include "postgres.h"
#include <limits.h>
#include "access/gist.h"
#include "access/stratnum.h"
2003-06-11 21:31:05 +02:00
#include "_int.h"
#define GETENTRY(vec,pos) ((ArrayType *) DatumGetPointer((vec)->vector[(pos)].key))
2003-06-11 21:31:05 +02:00
/*
* Control the maximum sparseness of compressed keys.
*
* The upper safe bound for this limit is half the maximum allocatable array
* size. A lower bound would give more guarantees that pathological data
* wouldn't eat excessive CPU and memory, but at the expense of breaking
* possibly working (after a fashion) indexes.
*/
#define MAXNUMELTS (Min((MaxAllocSize / sizeof(Datum)),((MaxAllocSize - ARR_OVERHEAD_NONULLS(1)) / sizeof(int)))/2)
/* or: #define MAXNUMELTS 1000000 */
2003-06-11 21:31:05 +02:00
/*
** GiST support methods
*/
PG_FUNCTION_INFO_V1(g_int_consistent);
PG_FUNCTION_INFO_V1(g_int_compress);
PG_FUNCTION_INFO_V1(g_int_decompress);
PG_FUNCTION_INFO_V1(g_int_penalty);
PG_FUNCTION_INFO_V1(g_int_picksplit);
PG_FUNCTION_INFO_V1(g_int_union);
PG_FUNCTION_INFO_V1(g_int_same);
/*
** The GiST Consistent method for _intments
** Should return false if for all data items x below entry,
** the predicate x op query == false, where op is the oper
2003-06-11 21:31:05 +02:00
** corresponding to strategy in the pg_amop table.
*/
Datum
g_int_consistent(PG_FUNCTION_ARGS)
{
GISTENTRY *entry = (GISTENTRY *) PG_GETARG_POINTER(0);
ArrayType *query = PG_GETARG_ARRAYTYPE_P_COPY(1);
2003-06-11 21:31:05 +02:00
StrategyNumber strategy = (StrategyNumber) PG_GETARG_UINT16(2);
/* Oid subtype = PG_GETARG_OID(3); */
bool *recheck = (bool *) PG_GETARG_POINTER(4);
2003-06-11 21:31:05 +02:00
bool retval;
/* this is exact except for RTSameStrategyNumber */
*recheck = (strategy == RTSameStrategyNumber);
if (strategy == BooleanSearchStrategy)
{
retval = execconsistent((QUERYTYPE *) query,
2003-06-11 21:31:05 +02:00
(ArrayType *) DatumGetPointer(entry->key),
GIST_LEAF(entry));
pfree(query);
PG_RETURN_BOOL(retval);
}
2003-06-11 21:31:05 +02:00
/* sort query for fast search, key is already sorted */
CHECKARRVALID(query);
2003-06-11 21:31:05 +02:00
PREPAREARR(query);
switch (strategy)
{
case RTOverlapStrategyNumber:
retval = inner_int_overlap((ArrayType *) DatumGetPointer(entry->key),
query);
break;
case RTSameStrategyNumber:
if (GIST_LEAF(entry))
DirectFunctionCall3(g_int_same,
2003-06-11 21:31:05 +02:00
entry->key,
PointerGetDatum(query),
PointerGetDatum(&retval));
2003-06-11 21:31:05 +02:00
else
retval = inner_int_contains((ArrayType *) DatumGetPointer(entry->key),
query);
break;
case RTContainsStrategyNumber:
case RTOldContainsStrategyNumber:
2003-06-11 21:31:05 +02:00
retval = inner_int_contains((ArrayType *) DatumGetPointer(entry->key),
query);
break;
case RTContainedByStrategyNumber:
case RTOldContainedByStrategyNumber:
2003-06-11 21:31:05 +02:00
if (GIST_LEAF(entry))
retval = inner_int_contains(query,
(ArrayType *) DatumGetPointer(entry->key));
else
Fix intarray's GiST opclasses to not fail for empty arrays with <@. contrib/intarray considers "arraycol <@ constant-array" to be indexable, but its GiST opclass code fails to reliably find index entries for empty array values (which of course should trivially match such queries). This is because the test condition to see whether we should descend through a non-leaf node is wrong. Unfortunately, empty array entries could be anywhere in the index, as these index opclasses are currently designed. So there's no way to fix this except by lobotomizing <@ indexscans to scan the whole index ... which is what this patch does. That's pretty unfortunate: the performance is now actually worse than a seqscan, in most cases. We'd be better off to remove <@ from the GiST opclasses entirely, and perhaps a future non-back-patchable patch will do so. In the meantime, applications whose performance is adversely impacted have a couple of options. They could switch to a GIN index, which doesn't have this bug, or they could replace "arraycol <@ constant-array" with "arraycol <@ constant-array AND arraycol && constant-array". That will provide about the same performance as before, and it will find all non-empty subsets of the given constant-array, which is all that could reliably be expected of the query before. While at it, add some more regression test cases to improve code coverage of contrib/intarray. In passing, adjust resize_intArrayType so that when it's returning an empty array, it uses construct_empty_array for that rather than cowboy hacking on the input array. While the hack produces an array that looks valid for most purposes, it isn't bitwise equal to empty arrays produced by other code paths, which could have subtle odd effects. I don't think this code path is performance-critical enough to justify such shortcuts. (Back-patch this part only as far as v11; before commit 01783ac36 we were not careful about this in other intarray code paths either.) Back-patch the <@ fixes to all supported versions, since this was broken from day one. Patch by me; thanks to Alexander Korotkov for review. Discussion: https://postgr.es/m/458.1565114141@sss.pgh.pa.us
2019-08-07 00:04:51 +02:00
{
/*
* Unfortunately, because empty arrays could be anywhere in
* the index, we must search the whole tree.
*/
retval = true;
}
2003-06-11 21:31:05 +02:00
break;
default:
retval = false;
2003-06-11 21:31:05 +02:00
}
pfree(query);
2003-06-11 21:31:05 +02:00
PG_RETURN_BOOL(retval);
}
Datum
g_int_union(PG_FUNCTION_ARGS)
{
GistEntryVector *entryvec = (GistEntryVector *) PG_GETARG_POINTER(0);
2003-06-11 21:31:05 +02:00
int *size = (int *) PG_GETARG_POINTER(1);
int32 i,
2003-06-11 21:31:05 +02:00
*ptr;
ArrayType *res;
int totlen = 0;
2003-06-11 21:31:05 +02:00
for (i = 0; i < entryvec->n; i++)
{
ArrayType *ent = GETENTRY(entryvec, i);
CHECKARRVALID(ent);
totlen += ARRNELEMS(ent);
}
2003-06-11 21:31:05 +02:00
res = new_intArrayType(totlen);
ptr = ARRPTR(res);
for (i = 0; i < entryvec->n; i++)
2003-06-11 21:31:05 +02:00
{
ArrayType *ent = GETENTRY(entryvec, i);
int nel;
nel = ARRNELEMS(ent);
memcpy(ptr, ARRPTR(ent), nel * sizeof(int32));
ptr += nel;
2003-06-11 21:31:05 +02:00
}
QSORT(res, 1);
res = _int_unique(res);
*size = VARSIZE(res);
PG_RETURN_POINTER(res);
}
/*
** GiST Compress and Decompress methods
*/
Datum
g_int_compress(PG_FUNCTION_ARGS)
{
GISTENTRY *entry = (GISTENTRY *) PG_GETARG_POINTER(0);
GISTENTRY *retval;
ArrayType *r;
int len,
lenr;
2003-06-11 21:31:05 +02:00
int *dr;
int i,
j,
2003-06-11 21:31:05 +02:00
cand;
int64 min;
2003-06-11 21:31:05 +02:00
if (entry->leafkey)
{
r = DatumGetArrayTypePCopy(entry->key);
CHECKARRVALID(r);
2003-06-11 21:31:05 +02:00
PREPAREARR(r);
if (ARRNELEMS(r) >= 2 * MAXNUMRANGE)
intarray: Prevent out-of-bound memory reads with gist__int_ops As gist__int_ops stands in intarray, it is possible to store GiST entries for leaf pages that can cause corruptions when decompressed. Leaf nodes are stored as decompressed all the time by the compression method, and the decompression method should map with that, retrieving the contents of the page without doing any decompression. However, the code authorized the insertion of leaf page data with a higher number of array items than what can be supported, generating a NOTICE message to inform about this matter (199 for a 8k page, for reference). When calling the decompression method, a decompression would be attempted on this leaf node item but the contents should be retrieved as they are. The NOTICE message generated when dealing with the compression of a leaf page and too many elements in the input array for gist__int_ops has been introduced by 08ee64e, removing the marker stored in the array to track if this is actually a leaf node. However, it also missed the fact that the decompression path should do nothing for a leaf page. Hence, as the code stand, a too-large array would be stored as uncompressed but the decompression path would attempt a decompression rather that retrieving the contents as they are. This leads to various problems. First, even if 08ee64e tried to address that, it is possible to do out-of-bound chunk writes with a large input array, with the backend informing about that with WARNINGs. On decompression, retrieving the stored leaf data would lead to incorrect memory reads, leading to crashes or even worse. Perhaps somebody would be interested in expanding the number of array items that can be handled in a leaf page for this operator in the future, which would require revisiting the choice done in 08ee64e, but based on the lack of reports about this problem since 2005 it does not look so. For now, this commit prevents the insertion of data for leaf pages when using more array items that the code can handle on decompression, switching the NOTICE message to an ERROR. If one wishes to use more array items, gist__intbig_ops is an optional choice. While on it, use ERRCODE_PROGRAM_LIMIT_EXCEEDED as error code when a limit is reached, because that's what the module is facing in such cases. Author: Ankit Kumar Pandey, Alexander Lakhin Reviewed-by: Richard Guo, Michael Paquier Discussion: https://postgr.es/m/796b65c3-57b7-bddf-b0d5-a8afafb8b627@gmail.com Discussion: https://postgr.es/m/17888-f72930e6b5ce8c14@postgresql.org Backpatch-through: 11
2023-06-15 06:45:42 +02:00
ereport(ERROR,
(errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED),
errmsg("input array is too big (%d maximum allowed, %d current), use gist__intbig_ops opclass instead",
2 * MAXNUMRANGE - 1, ARRNELEMS(r))));
2003-06-11 21:31:05 +02:00
retval = palloc(sizeof(GISTENTRY));
gistentryinit(*retval, PointerGetDatum(r),
entry->rel, entry->page, entry->offset, false);
2003-06-11 21:31:05 +02:00
PG_RETURN_POINTER(retval);
}
/*
* leaf entries never compress one more time, only when entry->leafkey
* ==true, so now we work only with internal keys
*/
r = DatumGetArrayTypeP(entry->key);
CHECKARRVALID(r);
if (ARRISEMPTY(r))
2003-06-11 21:31:05 +02:00
{
if (r != (ArrayType *) DatumGetPointer(entry->key))
pfree(r);
PG_RETURN_POINTER(entry);
}
if ((len = ARRNELEMS(r)) >= 2 * MAXNUMRANGE)
{ /* compress */
if (r == (ArrayType *) DatumGetPointer(entry->key))
r = DatumGetArrayTypePCopy(entry->key);
2003-06-11 21:31:05 +02:00
r = resize_intArrayType(r, 2 * (len));
dr = ARRPTR(r);
/*
* "len" at this point is the number of ranges we will construct.
* "lenr" is the number of ranges we must eventually remove by
* merging, we must be careful to remove no more than this number.
*/
lenr = len - MAXNUMRANGE;
/*
* Initially assume we can merge consecutive ints into a range. but we
* must count every value removed and stop when lenr runs out
*/
for (j = i = len - 1; i > 0 && lenr > 0; i--, j--)
{
int r_end = dr[i];
int r_start = r_end;
while (i > 0 && lenr > 0 && dr[i - 1] == r_start - 1)
--r_start, --i, --lenr;
dr[2 * j] = r_start;
dr[2 * j + 1] = r_end;
}
/* just copy the rest, if any, as trivial ranges */
for (; i >= 0; i--, j--)
dr[2 * j] = dr[2 * j + 1] = dr[i];
2003-06-11 21:31:05 +02:00
if (++j)
{
/*
* shunt everything down to start at the right place
*/
memmove((void *) &dr[0], (void *) &dr[2 * j], 2 * (len - j) * sizeof(int32));
}
/*
* make "len" be number of array elements, not ranges
*/
len = 2 * (len - j);
2003-06-11 21:31:05 +02:00
cand = 1;
while (len > MAXNUMRANGE * 2)
{
min = PG_INT64_MAX;
2003-06-11 21:31:05 +02:00
for (i = 2; i < len; i += 2)
if (min > ((int64) dr[i] - (int64) dr[i - 1]))
2003-06-11 21:31:05 +02:00
{
min = ((int64) dr[i] - (int64) dr[i - 1]);
2003-06-11 21:31:05 +02:00
cand = i;
}
memmove((void *) &dr[cand - 1], (void *) &dr[cand + 1], (len - cand - 1) * sizeof(int32));
2003-06-11 21:31:05 +02:00
len -= 2;
}
/*
* check sparseness of result
*/
lenr = internal_size(dr, len);
if (lenr < 0 || lenr > MAXNUMELTS)
ereport(ERROR,
intarray: Prevent out-of-bound memory reads with gist__int_ops As gist__int_ops stands in intarray, it is possible to store GiST entries for leaf pages that can cause corruptions when decompressed. Leaf nodes are stored as decompressed all the time by the compression method, and the decompression method should map with that, retrieving the contents of the page without doing any decompression. However, the code authorized the insertion of leaf page data with a higher number of array items than what can be supported, generating a NOTICE message to inform about this matter (199 for a 8k page, for reference). When calling the decompression method, a decompression would be attempted on this leaf node item but the contents should be retrieved as they are. The NOTICE message generated when dealing with the compression of a leaf page and too many elements in the input array for gist__int_ops has been introduced by 08ee64e, removing the marker stored in the array to track if this is actually a leaf node. However, it also missed the fact that the decompression path should do nothing for a leaf page. Hence, as the code stand, a too-large array would be stored as uncompressed but the decompression path would attempt a decompression rather that retrieving the contents as they are. This leads to various problems. First, even if 08ee64e tried to address that, it is possible to do out-of-bound chunk writes with a large input array, with the backend informing about that with WARNINGs. On decompression, retrieving the stored leaf data would lead to incorrect memory reads, leading to crashes or even worse. Perhaps somebody would be interested in expanding the number of array items that can be handled in a leaf page for this operator in the future, which would require revisiting the choice done in 08ee64e, but based on the lack of reports about this problem since 2005 it does not look so. For now, this commit prevents the insertion of data for leaf pages when using more array items that the code can handle on decompression, switching the NOTICE message to an ERROR. If one wishes to use more array items, gist__intbig_ops is an optional choice. While on it, use ERRCODE_PROGRAM_LIMIT_EXCEEDED as error code when a limit is reached, because that's what the module is facing in such cases. Author: Ankit Kumar Pandey, Alexander Lakhin Reviewed-by: Richard Guo, Michael Paquier Discussion: https://postgr.es/m/796b65c3-57b7-bddf-b0d5-a8afafb8b627@gmail.com Discussion: https://postgr.es/m/17888-f72930e6b5ce8c14@postgresql.org Backpatch-through: 11
2023-06-15 06:45:42 +02:00
(errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED),
errmsg("data is too sparse, recreate index using gist__intbig_ops opclass instead")));
2003-06-11 21:31:05 +02:00
r = resize_intArrayType(r, len);
retval = palloc(sizeof(GISTENTRY));
gistentryinit(*retval, PointerGetDatum(r),
entry->rel, entry->page, entry->offset, false);
2003-06-11 21:31:05 +02:00
PG_RETURN_POINTER(retval);
}
else
PG_RETURN_POINTER(entry);
}
Datum
g_int_decompress(PG_FUNCTION_ARGS)
{
GISTENTRY *entry = (GISTENTRY *) PG_GETARG_POINTER(0);
GISTENTRY *retval;
ArrayType *r;
int *dr,
lenr;
ArrayType *in;
int lenin;
int *din;
int i;
2003-06-11 21:31:05 +02:00
in = DatumGetArrayTypeP(entry->key);
2003-06-11 21:31:05 +02:00
CHECKARRVALID(in);
if (ARRISEMPTY(in))
{
if (in != (ArrayType *) DatumGetPointer(entry->key))
{
retval = palloc(sizeof(GISTENTRY));
gistentryinit(*retval, PointerGetDatum(in),
entry->rel, entry->page, entry->offset, false);
PG_RETURN_POINTER(retval);
}
2003-06-11 21:31:05 +02:00
PG_RETURN_POINTER(entry);
}
2003-06-11 21:31:05 +02:00
lenin = ARRNELEMS(in);
if (lenin < 2 * MAXNUMRANGE)
2003-06-11 21:31:05 +02:00
{ /* not compressed value */
if (in != (ArrayType *) DatumGetPointer(entry->key))
{
retval = palloc(sizeof(GISTENTRY));
gistentryinit(*retval, PointerGetDatum(in),
entry->rel, entry->page, entry->offset, false);
2003-06-11 21:31:05 +02:00
PG_RETURN_POINTER(retval);
}
PG_RETURN_POINTER(entry);
}
din = ARRPTR(in);
lenr = internal_size(din, lenin);
if (lenr < 0 || lenr > MAXNUMELTS)
ereport(ERROR,
intarray: Prevent out-of-bound memory reads with gist__int_ops As gist__int_ops stands in intarray, it is possible to store GiST entries for leaf pages that can cause corruptions when decompressed. Leaf nodes are stored as decompressed all the time by the compression method, and the decompression method should map with that, retrieving the contents of the page without doing any decompression. However, the code authorized the insertion of leaf page data with a higher number of array items than what can be supported, generating a NOTICE message to inform about this matter (199 for a 8k page, for reference). When calling the decompression method, a decompression would be attempted on this leaf node item but the contents should be retrieved as they are. The NOTICE message generated when dealing with the compression of a leaf page and too many elements in the input array for gist__int_ops has been introduced by 08ee64e, removing the marker stored in the array to track if this is actually a leaf node. However, it also missed the fact that the decompression path should do nothing for a leaf page. Hence, as the code stand, a too-large array would be stored as uncompressed but the decompression path would attempt a decompression rather that retrieving the contents as they are. This leads to various problems. First, even if 08ee64e tried to address that, it is possible to do out-of-bound chunk writes with a large input array, with the backend informing about that with WARNINGs. On decompression, retrieving the stored leaf data would lead to incorrect memory reads, leading to crashes or even worse. Perhaps somebody would be interested in expanding the number of array items that can be handled in a leaf page for this operator in the future, which would require revisiting the choice done in 08ee64e, but based on the lack of reports about this problem since 2005 it does not look so. For now, this commit prevents the insertion of data for leaf pages when using more array items that the code can handle on decompression, switching the NOTICE message to an ERROR. If one wishes to use more array items, gist__intbig_ops is an optional choice. While on it, use ERRCODE_PROGRAM_LIMIT_EXCEEDED as error code when a limit is reached, because that's what the module is facing in such cases. Author: Ankit Kumar Pandey, Alexander Lakhin Reviewed-by: Richard Guo, Michael Paquier Discussion: https://postgr.es/m/796b65c3-57b7-bddf-b0d5-a8afafb8b627@gmail.com Discussion: https://postgr.es/m/17888-f72930e6b5ce8c14@postgresql.org Backpatch-through: 11
2023-06-15 06:45:42 +02:00
(errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED),
errmsg("compressed array is too big, recreate index using gist__intbig_ops opclass instead")));
2003-06-11 21:31:05 +02:00
r = new_intArrayType(lenr);
dr = ARRPTR(r);
for (i = 0; i < lenin; i += 2)
{
/* use int64 for j in case din[i + 1] is INT_MAX */
for (int64 j = din[i]; j <= din[i + 1]; j++)
2003-06-11 21:31:05 +02:00
if ((!i) || *(dr - 1) != j)
*dr++ = (int) j;
}
2003-06-11 21:31:05 +02:00
if (in != (ArrayType *) DatumGetPointer(entry->key))
pfree(in);
retval = palloc(sizeof(GISTENTRY));
gistentryinit(*retval, PointerGetDatum(r),
entry->rel, entry->page, entry->offset, false);
2003-06-11 21:31:05 +02:00
PG_RETURN_POINTER(retval);
}
/*
** The GiST Penalty method for _intments
*/
Datum
g_int_penalty(PG_FUNCTION_ARGS)
{
GISTENTRY *origentry = (GISTENTRY *) PG_GETARG_POINTER(0);
GISTENTRY *newentry = (GISTENTRY *) PG_GETARG_POINTER(1);
float *result = (float *) PG_GETARG_POINTER(2);
ArrayType *ud;
float tmp1,
tmp2;
ud = inner_int_union((ArrayType *) DatumGetPointer(origentry->key),
(ArrayType *) DatumGetPointer(newentry->key));
rt__int_size(ud, &tmp1);
rt__int_size((ArrayType *) DatumGetPointer(origentry->key), &tmp2);
*result = tmp1 - tmp2;
pfree(ud);
PG_RETURN_POINTER(result);
}
Datum
g_int_same(PG_FUNCTION_ARGS)
{
ArrayType *a = PG_GETARG_ARRAYTYPE_P(0);
ArrayType *b = PG_GETARG_ARRAYTYPE_P(1);
2003-06-11 21:31:05 +02:00
bool *result = (bool *) PG_GETARG_POINTER(2);
int32 n = ARRNELEMS(a);
int32 *da,
2003-06-11 21:31:05 +02:00
*db;
CHECKARRVALID(a);
CHECKARRVALID(b);
2003-06-11 21:31:05 +02:00
if (n != ARRNELEMS(b))
{
*result = false;
PG_RETURN_POINTER(result);
}
*result = true;
2003-06-11 21:31:05 +02:00
da = ARRPTR(a);
db = ARRPTR(b);
while (n--)
{
2003-06-11 21:31:05 +02:00
if (*da++ != *db++)
{
*result = false;
2003-06-11 21:31:05 +02:00
break;
}
}
2003-06-11 21:31:05 +02:00
PG_RETURN_POINTER(result);
}
/*****************************************************************
** Common GiST Method
*****************************************************************/
typedef struct
{
OffsetNumber pos;
float cost;
} SPLITCOST;
static int
comparecost(const void *a, const void *b)
{
if (((const SPLITCOST *) a)->cost == ((const SPLITCOST *) b)->cost)
2003-06-11 21:31:05 +02:00
return 0;
else
return (((const SPLITCOST *) a)->cost > ((const SPLITCOST *) b)->cost) ? 1 : -1;
2003-06-11 21:31:05 +02:00
}
/*
** The GiST PickSplit method for _intments
** We use Guttman's poly time split algorithm
*/
Datum
g_int_picksplit(PG_FUNCTION_ARGS)
{
GistEntryVector *entryvec = (GistEntryVector *) PG_GETARG_POINTER(0);
2003-06-11 21:31:05 +02:00
GIST_SPLITVEC *v = (GIST_SPLITVEC *) PG_GETARG_POINTER(1);
OffsetNumber i,
j;
ArrayType *datum_alpha,
*datum_beta;
ArrayType *datum_l,
*datum_r;
ArrayType *union_d,
*union_dl,
*union_dr;
ArrayType *inter_d;
bool firsttime;
float size_alpha,
size_beta,
size_union,
size_inter;
float size_waste,
waste;
float size_l,
size_r;
int nbytes;
OffsetNumber seed_1 = 0,
seed_2 = 0;
OffsetNumber *left,
*right;
OffsetNumber maxoff;
SPLITCOST *costvector;
#ifdef GIST_DEBUG
elog(DEBUG3, "--------picksplit %d", entryvec->n);
2003-06-11 21:31:05 +02:00
#endif
maxoff = entryvec->n - 2;
2003-06-11 21:31:05 +02:00
nbytes = (maxoff + 2) * sizeof(OffsetNumber);
v->spl_left = (OffsetNumber *) palloc(nbytes);
v->spl_right = (OffsetNumber *) palloc(nbytes);
firsttime = true;
waste = 0.0;
for (i = FirstOffsetNumber; i < maxoff; i = OffsetNumberNext(i))
{
datum_alpha = GETENTRY(entryvec, i);
2003-06-11 21:31:05 +02:00
for (j = OffsetNumberNext(i); j <= maxoff; j = OffsetNumberNext(j))
{
datum_beta = GETENTRY(entryvec, j);
2003-06-11 21:31:05 +02:00
/* compute the wasted space by unioning these guys */
/* size_waste = size_union - size_inter; */
union_d = inner_int_union(datum_alpha, datum_beta);
rt__int_size(union_d, &size_union);
inter_d = inner_int_inter(datum_alpha, datum_beta);
rt__int_size(inter_d, &size_inter);
size_waste = size_union - size_inter;
pfree(union_d);
pfree(inter_d);
2003-06-11 21:31:05 +02:00
/*
* are these a more promising split that what we've already seen?
*/
if (size_waste > waste || firsttime)
{
waste = size_waste;
seed_1 = i;
seed_2 = j;
firsttime = false;
}
}
}
left = v->spl_left;
v->spl_nleft = 0;
right = v->spl_right;
v->spl_nright = 0;
if (seed_1 == 0 || seed_2 == 0)
{
seed_1 = 1;
seed_2 = 2;
}
datum_alpha = GETENTRY(entryvec, seed_1);
2003-06-11 21:31:05 +02:00
datum_l = copy_intArrayType(datum_alpha);
rt__int_size(datum_l, &size_l);
datum_beta = GETENTRY(entryvec, seed_2);
2003-06-11 21:31:05 +02:00
datum_r = copy_intArrayType(datum_beta);
rt__int_size(datum_r, &size_r);
maxoff = OffsetNumberNext(maxoff);
/*
* sort entries
*/
costvector = (SPLITCOST *) palloc(sizeof(SPLITCOST) * maxoff);
for (i = FirstOffsetNumber; i <= maxoff; i = OffsetNumberNext(i))
{
costvector[i - 1].pos = i;
datum_alpha = GETENTRY(entryvec, i);
2003-06-11 21:31:05 +02:00
union_d = inner_int_union(datum_l, datum_alpha);
rt__int_size(union_d, &size_alpha);
pfree(union_d);
union_d = inner_int_union(datum_r, datum_alpha);
rt__int_size(union_d, &size_beta);
pfree(union_d);
costvector[i - 1].cost = Abs((size_alpha - size_l) - (size_beta - size_r));
2003-06-11 21:31:05 +02:00
}
qsort((void *) costvector, maxoff, sizeof(SPLITCOST), comparecost);
/*
* Now split up the regions between the two seeds. An important property
* of this split algorithm is that the split vector v has the indices of
* items to be split in order in its left and right vectors. We exploit
* this property by doing a merge in the code that actually splits the
* page.
*
* For efficiency, we also place the new index tuple in this loop. This is
* handled at the very end, when we have placed all the existing tuples
* and i == maxoff + 1.
*/
for (j = 0; j < maxoff; j++)
{
i = costvector[j].pos;
/*
* If we've already decided where to place this item, just put it on
* the right list. Otherwise, we need to figure out which page needs
* the least enlargement in order to store the item.
*/
if (i == seed_1)
{
*left++ = i;
v->spl_nleft++;
continue;
}
else if (i == seed_2)
{
*right++ = i;
v->spl_nright++;
continue;
}
/* okay, which page needs least enlargement? */
datum_alpha = GETENTRY(entryvec, i);
2003-06-11 21:31:05 +02:00
union_dl = inner_int_union(datum_l, datum_alpha);
union_dr = inner_int_union(datum_r, datum_alpha);
rt__int_size(union_dl, &size_alpha);
rt__int_size(union_dr, &size_beta);
/* pick which page to add it to */
if (size_alpha - size_l < size_beta - size_r + WISH_F(v->spl_nleft, v->spl_nright, 0.01))
{
pfree(datum_l);
pfree(union_dr);
2003-06-11 21:31:05 +02:00
datum_l = union_dl;
size_l = size_alpha;
*left++ = i;
v->spl_nleft++;
}
else
{
pfree(datum_r);
pfree(union_dl);
2003-06-11 21:31:05 +02:00
datum_r = union_dr;
size_r = size_beta;
*right++ = i;
v->spl_nright++;
}
}
pfree(costvector);
*right = *left = FirstOffsetNumber;
v->spl_ldatum = PointerGetDatum(datum_l);
v->spl_rdatum = PointerGetDatum(datum_r);
PG_RETURN_POINTER(v);
}