public inbox for [email protected]
help / color / mirror / Atom feed[PATCH] Fix FK name when colliding during partition attachment
12+ messages / 5 participants
[nested] [flat]
* [PATCH] Fix FK name when colliding during partition attachment
@ 2022-09-01 15:41 Jehan-Guillaume de Rorthais <[email protected]>
0 siblings, 0 replies; 12+ messages in thread
From: Jehan-Guillaume de Rorthais @ 2022-09-01 15:41 UTC (permalink / raw)
During ATLER TABLE ATTACH PARTITION, if the name of a parent's
foreign key constraint is already used on the partition, the code
try to choose another one before the FK attributes list has been
populated. The resulting constraint name was a strange
"<relname>__fkey" instead of "<relname>_<attrs>_fkey".
---
src/backend/commands/tablecmds.c | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c
index dacc989d85..53b0f3a9c1 100644
--- a/src/backend/commands/tablecmds.c
+++ b/src/backend/commands/tablecmds.c
@@ -10304,16 +10304,6 @@ CloneFkReferencing(List **wqueue, Relation parentRel, Relation partRel)
/* No dice. Set up to create our own constraint */
fkconstraint = makeNode(Constraint);
- if (ConstraintNameIsUsed(CONSTRAINT_RELATION,
- RelationGetRelid(partRel),
- NameStr(constrForm->conname)))
- fkconstraint->conname =
- ChooseConstraintName(RelationGetRelationName(partRel),
- ChooseForeignKeyConstraintNameAddition(fkconstraint->fk_attrs),
- "fkey",
- RelationGetNamespace(partRel), NIL);
- else
- fkconstraint->conname = pstrdup(NameStr(constrForm->conname));
fkconstraint->fk_upd_action = constrForm->confupdtype;
fkconstraint->fk_del_action = constrForm->confdeltype;
fkconstraint->deferrable = constrForm->condeferrable;
@@ -10328,6 +10318,16 @@ CloneFkReferencing(List **wqueue, Relation parentRel, Relation partRel)
fkconstraint->fk_attrs = lappend(fkconstraint->fk_attrs,
makeString(NameStr(att->attname)));
}
+ if (ConstraintNameIsUsed(CONSTRAINT_RELATION,
+ RelationGetRelid(partRel),
+ NameStr(constrForm->conname)))
+ fkconstraint->conname =
+ ChooseConstraintName(RelationGetRelationName(partRel),
+ ChooseForeignKeyConstraintNameAddition(fkconstraint->fk_attrs),
+ "fkey",
+ RelationGetNamespace(partRel), NIL);
+ else
+ fkconstraint->conname = pstrdup(NameStr(constrForm->conname));
indexOid = constrForm->conindid;
constrOid =
--
2.37.2
--MP_/dajHgyhUOhl1wTbdYuIRFBX--
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan
@ 2023-11-07 12:20 Matthias van de Meent <[email protected]>
2023-11-08 01:53 ` Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan Peter Geoghegan <[email protected]>
0 siblings, 1 reply; 12+ messages in thread
From: Matthias van de Meent @ 2023-11-07 12:20 UTC (permalink / raw)
To: Peter Geoghegan <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>; Tom Lane <[email protected]>; Tomas Vondra <[email protected]>; Jeff Davis <[email protected]>; benoit <[email protected]>; Alexander Korotkov <[email protected]>
On Tue, 7 Nov 2023 at 00:03, Peter Geoghegan <[email protected]> wrote:
>
> On Mon, Nov 6, 2023 at 1:28 PM Matthias van de Meent
> <[email protected]> wrote:
> > I'm planning on reviewing this patch tomorrow, but in an initial scan
> > through the patch I noticed there's little information about how the
> > array keys state machine works in this new design. Do you have a more
> > toplevel description of the full state machine used in the new design?
>
> This is an excellent question. You're entirely right: there isn't
> enough information about the design of the state machine.
>
> I should be able to post v6 later this week. My current plan is to
> commit the other nbtree patch first (the backwards scan "boundary
> cases" one from the ongoing CF) -- since I saw your review earlier
> today. I think that you should probably wait for this v6 before
> starting your review.
Okay, thanks for the update, then I'll wait for v6 to be posted.
Kind regards,
Matthias van de Meent
Neon (https://neon.tech)
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan
2023-11-07 12:20 Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan Matthias van de Meent <[email protected]>
@ 2023-11-08 01:53 ` Peter Geoghegan <[email protected]>
2023-11-09 23:57 ` Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan Peter Geoghegan <[email protected]>
2023-11-11 21:08 ` Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan Matthias van de Meent <[email protected]>
0 siblings, 2 replies; 12+ messages in thread
From: Peter Geoghegan @ 2023-11-08 01:53 UTC (permalink / raw)
To: Matthias van de Meent <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>; Tom Lane <[email protected]>; Tomas Vondra <[email protected]>; Jeff Davis <[email protected]>; benoit <[email protected]>; Alexander Korotkov <[email protected]>
On Tue, Nov 7, 2023 at 4:20 AM Matthias van de Meent
<[email protected]> wrote:
> On Tue, 7 Nov 2023 at 00:03, Peter Geoghegan <[email protected]> wrote:
> > I should be able to post v6 later this week. My current plan is to
> > commit the other nbtree patch first (the backwards scan "boundary
> > cases" one from the ongoing CF) -- since I saw your review earlier
> > today. I think that you should probably wait for this v6 before
> > starting your review.
>
> Okay, thanks for the update, then I'll wait for v6 to be posted.
On second thought, I'll just post v6 now (there won't be conflicts
against the master branch once the other patch is committed anyway).
Highlights:
* Major simplifications to the array key state machine, already
described by my recent email.
* Added preprocessing of "redundant and contradictory" array elements
to _bt_preprocess_array_keys().
This makes the special preprocessing pass just for array keys
("preprocessing preprocessing") within _bt_preprocess_array_keys()
make this query into a no-op:
select * from tab where a in (180, 345) and a in (230, 300); -- contradictory
Similarly, it can make this query only attempt one single primitive
index scan for "230":
select * from tab where a in (180, 230) and a in (230, 300); -- has
redundancies, plus some individual elements contradict each other
This duplicates some of what _bt_preprocess_keys can do already. But
_bt_preprocess_keys can only do this stuff at the level of individual
array elements/primitive index scans. Whereas this works "one level
up", allowing preprocessing to see the full picture rather than just
seeing the start of one particular primitive index scan. It explicitly
works across array keys, saving repeat work inside
_bt_preprocess_keys. That could really add up with thousands of array
keys and/or multiple SAOPs. (Note that _bt_preprocess_array_keys
already does something like this, to deal with SAOP inequalities such
as "WHERE my_col >= any (array[1, 2])" -- it's a little surprising
that this obvious optimization wasn't part of the original nbtree SAOP
patch.)
This reminds me: you might want to try breaking the patch by coming up
with adversarial cases, Matthias. The patch needs to be able to deal
with absurdly large amounts of array keys reasonably well, because it
proposes to normalize passing those to the nbtree code. It's
especially important that the patch never takes too much time to do
something (e.g., binary searching through array keys) while holding a
buffer lock -- even with very silly adversarial queries.
So, for example, queries like this one (specifically designed to
stress the implementation) *need* to work reasonably well:
with a as (
select i from generate_series(0, 500000) i
)
select
count(*), thousand, tenthous
from
tenk1
where
thousand = any (array[(select array_agg(i) from a)]) and
tenthous = any (array[(select array_agg(i) from a)])
group by
thousand, tenthous
order by
thousand, tenthous;
(You can run this yourself after the regression tests finish, of course.)
This takes about 130ms on my machine, hardly any of which takes place
in the nbtree code with the patch (think tens of microseconds per
_bt_readpage call, at most) -- the plan is an index-only scan that
gets only 30 buffer hits. On the master branch, it's vastly slower --
1000025 buffer hits. The query as a whole takes about 3 seconds there.
If you have 3 or 4 SOAPs (with a composite index that has as many
columns) you can quite easily DOS the master branch, since the planner
makes a generic assumption that each of these SOAPs will have only 10
elements. The planner also thinks that with the patch applied, with
one important difference: it doesn't matter to nbtree. The cost of
scanning each index page should be practically independent of the
total size of each array, at least past a certain point. Similarly,
the maximum cost of an index scan should be approximately fixed: it
should be capped at the cost of a full index scan (with the added cost
of these relatively expensive quals still capped, still essentially
independent of array sizes past some point).
I notice that if I remove the "thousand = any (array[(select
array_agg(i) from a)]) and" line from the adversarial query, executing
the resulting query still get 30 buffer hits with the patch -- though
it only takes 90ms this time (it's faster for reasons that likely have
less than you'd think to do with nbtree overheads). This is just
another way of getting roughly the same full index scan. That's a
completely new way of thinking about nbtree SAOPs from a planner
perspective (also from a user's perspective, I suppose).
It's important that the planner's new optimistic assumptions about the
cost profile of SOAPS (that it can expect reasonable
performance/access patterns with wildly unreasonable/huge/arbitrarily
complicated SAOPs) always be met by nbtree -- no repeat index page
accesses, no holding a buffer lock for more than (say) a small
fraction of 1 millisecond (no matter the complexity of the query), and
possibly other things I haven't thought of yet.
If you end up finding a bug in this v6, it'll most likely be a case
where nbtree fails to live up to that. This project is as much about
robust/predictable performance as anything else -- nbtree needs to be
able to cope with practically anything. I suggest that your review
start by trying to break the patch along these lines.
--
Peter Geoghegan
Attachments:
[application/octet-stream] v6-0001-Enhance-nbtree-ScalarArrayOp-execution.patch (115.3K, ../../CAH2-Wz=Ct9fLcN-2SV0gx_iBk87RsAi+Sor3OwR2_5Rg_KO0+g@mail.gmail.com/2-v6-0001-Enhance-nbtree-ScalarArrayOp-execution.patch)
download | inline diff:
From 1ae97d26aa5a1fb3e7dafc4160960bc144e4be9e Mon Sep 17 00:00:00 2001
From: Peter Geoghegan <[email protected]>
Date: Sat, 17 Jun 2023 17:03:36 -0700
Subject: [PATCH v6] Enhance nbtree ScalarArrayOp execution.
Commit 9e8da0f7 taught nbtree to handle ScalarArrayOpExpr quals
natively. This works by pushing additional context about the arrays
down into the nbtree index AM, as index quals. This information enabled
nbtree to execute multiple primitive index scans as part of an index
scan executor node that was treated as one continuous index scan.
The motivation behind this earlier work was enabling index-only scans
with ScalarArrayOpExpr clauses (SAOP quals are traditionally executed
via BitmapOr nodes, which is largely index-AM-agnostic, but always
requires heap access). The general idea of giving the index AM this
additional context can be pushed a lot further, though.
Teach nbtree SAOP index scans to advance array scan keys by applying
information about the physical characteristics of the index at runtime.
The array key state machine advances the current array keys using the
next index tuple in line to be scanned, at the point where the scan
reaches the end of index tuples matching its current array keys. We
dynamically decide whether to perform another primitive index scan (or
whether to stick with the ongoing leaf level traversal) using a set of
heuristics that aim to minimize repeat index descents. This approach
can be far more efficient: many cases that previously required thousands
of primitive index scans now require as few as one single primitive
index scan. All duplicative index page accesses are now avoided.
nbtree can now execute required and non-required array/SAOP scan keys in
the most efficient way possible. Naturally, only required SAOP keys
(i.e. those that can terminate the top-level scan) are capable of
triggering a new primitive index scan; non-required keys never affect
the scan's position. Consequently, index scans on a composite index
with (say) a high-order inequality key and a low-order SAOP key (which
nbtree will make into a non-required scan key) will now reliably output
rows in index order. The scan is always executed as one large index
scan under the hood, which is obviously the fastest way to do it, for
the usual reasons: it avoids useless repeat index page accesses across
successive primitive index scans. More importantly, nbtree's very
general approach removes any question of index scan nodes outputting
rows in an order that doesn't match the index. This enables the removal
of various special cases from the planner -- which in turn makes the
nbtree enhancements more effective and more widely applicable.
Bugfix commit 807a40c5 taught the planner to avoid generating unsafe
path keys: path keys on a multicolumn index path, with a SAOP clause on
any attribute beyond the first/most significant attribute. These cases
are now all safe, so we go back to generating path keys without regard
for the presence of SAOP clauses (just like with any other clause type).
Also undo changes from follow-up bugfix commit a4523c5a, which taught
the planner to produce alternative index paths without low-order
ScalarArrayOpExpr quals (paths where the quals appear as filter quals
instead). Now there is never any need to make a cost-based choice
between an index scan that can be trusted to return tuples in index
order (but has SAOP filter quals), and a more selective index scan that
can apply true SAOP index quals for one or more low-order index columns
(but cannot be trusted to produce tuples in index order).
Many of the queries sped up by the enhancements added by this commit
won't benefit much from avoiding repeat index page accesses. The most
compelling cases are those where query execution _completely_ avoids
many heap page accesses that filter quals would have otherwise required,
just to eliminate one or more non-matching rows from each heap page.
(In general, index scan filter quals always need "extra" heap accesses
to eliminate non-matching rows, since expression evaluation is only
deemed safe with visible rows. Whereas index quals never require inline
visibility checks; they can just eliminate non-matching rows up front.)
Author: Peter Geoghegan <[email protected]>
Discussion: https://postgr.es/m/CAH2-Wz=ksvN_sjcnD1+Bt-WtifRA5ok48aDYnq3pkKhxgMQpcw@mail.gmail.com
---
src/include/access/nbtree.h | 42 +-
src/backend/access/nbtree/nbtree.c | 63 +-
src/backend/access/nbtree/nbtsearch.c | 92 +-
src/backend/access/nbtree/nbtutils.c | 1472 +++++++++++++++++++-
src/backend/optimizer/path/indxpath.c | 86 +-
src/backend/utils/adt/selfuncs.c | 122 +-
doc/src/sgml/monitoring.sgml | 13 +
src/test/regress/expected/create_index.out | 61 +-
src/test/regress/expected/join.out | 5 +-
src/test/regress/sql/create_index.sql | 20 +-
10 files changed, 1700 insertions(+), 276 deletions(-)
diff --git a/src/include/access/nbtree.h b/src/include/access/nbtree.h
index 7bfbf3086..566e1c15d 100644
--- a/src/include/access/nbtree.h
+++ b/src/include/access/nbtree.h
@@ -965,7 +965,7 @@ typedef struct BTScanPosData
* moreLeft and moreRight track whether we think there may be matching
* index entries to the left and right of the current page, respectively.
* We can clear the appropriate one of these flags when _bt_checkkeys()
- * returns continuescan = false.
+ * sets BTReadPageState.continuescan = false.
*/
bool moreLeft;
bool moreRight;
@@ -1043,13 +1043,13 @@ typedef struct BTScanOpaqueData
/* workspace for SK_SEARCHARRAY support */
ScanKey arrayKeyData; /* modified copy of scan->keyData */
- bool arraysStarted; /* Started array keys, but have yet to "reach
- * past the end" of all arrays? */
int numArrayKeys; /* number of equality-type array keys (-1 if
* there are any unsatisfiable array keys) */
- int arrayKeyCount; /* count indicating number of array scan keys
- * processed */
+ bool needPrimScan; /* Perform another primitive scan? */
BTArrayKeyInfo *arrayKeys; /* info about each equality-type array key */
+ FmgrInfo *orderProcs; /* ORDER procs for equality constraint keys */
+ int numPrimScans; /* Running tally of # primitive index scans
+ * (used to coordinate parallel workers) */
MemoryContext arrayContext; /* scan-lifespan context for array data */
/* info about killed items if any (killedItems is NULL if never used) */
@@ -1083,6 +1083,29 @@ typedef struct BTScanOpaqueData
typedef BTScanOpaqueData *BTScanOpaque;
+/*
+ * _bt_readpage state used across _bt_checkkeys calls for a page
+ *
+ * When _bt_readpage is called during a forward scan that has one or more
+ * equality-type SK_SEARCHARRAY scan keys, it has an extra responsibility: to
+ * set up information about the final tuple from the page. This must happen
+ * before the first call to _bt_checkkeys. _bt_checkkeys uses the final tuple
+ * to manage advancement of the scan's array keys more efficiently.
+ */
+typedef struct BTReadPageState
+{
+ /* Input parameters, set by _bt_readpage */
+ ScanDirection dir; /* current scan direction */
+ IndexTuple finaltup; /* final tuple (high key for forward scans) */
+
+ /* Output parameters, set by _bt_checkkeys */
+ bool continuescan; /* Terminate ongoing (primitive) index scan? */
+
+ /* Private _bt_checkkeys-managed state */
+ bool finaltupchecked; /* final tuple checked against current
+ * SK_SEARCHARRAY array keys? */
+} BTReadPageState;
+
/*
* We use some private sk_flags bits in preprocessed scan keys. We're allowed
* to use bits 16-31 (see skey.h). The uppermost bits are copied from the
@@ -1090,6 +1113,7 @@ typedef BTScanOpaqueData *BTScanOpaque;
*/
#define SK_BT_REQFWD 0x00010000 /* required to continue forward scan */
#define SK_BT_REQBKWD 0x00020000 /* required to continue backward scan */
+#define SK_BT_RDDNARRAY 0x00040000 /* redundant in array preprocessing */
#define SK_BT_INDOPTION_SHIFT 24 /* must clear the above bits */
#define SK_BT_DESC (INDOPTION_DESC << SK_BT_INDOPTION_SHIFT)
#define SK_BT_NULLS_FIRST (INDOPTION_NULLS_FIRST << SK_BT_INDOPTION_SHIFT)
@@ -1160,7 +1184,7 @@ extern bool btcanreturn(Relation index, int attno);
extern bool _bt_parallel_seize(IndexScanDesc scan, BlockNumber *pageno);
extern void _bt_parallel_release(IndexScanDesc scan, BlockNumber scan_page);
extern void _bt_parallel_done(IndexScanDesc scan);
-extern void _bt_parallel_advance_array_keys(IndexScanDesc scan);
+extern void _bt_parallel_next_primitive_scan(IndexScanDesc scan);
/*
* prototypes for functions in nbtdedup.c
@@ -1253,12 +1277,12 @@ extern BTScanInsert _bt_mkscankey(Relation rel, IndexTuple itup);
extern void _bt_freestack(BTStack stack);
extern void _bt_preprocess_array_keys(IndexScanDesc scan);
extern void _bt_start_array_keys(IndexScanDesc scan, ScanDirection dir);
-extern bool _bt_advance_array_keys(IndexScanDesc scan, ScanDirection dir);
+extern bool _bt_array_keys_remain(IndexScanDesc scan, ScanDirection dir);
extern void _bt_mark_array_keys(IndexScanDesc scan);
extern void _bt_restore_array_keys(IndexScanDesc scan);
extern void _bt_preprocess_keys(IndexScanDesc scan);
-extern bool _bt_checkkeys(IndexScanDesc scan, IndexTuple tuple,
- int tupnatts, ScanDirection dir, bool *continuescan,
+extern bool _bt_checkkeys(IndexScanDesc scan, BTReadPageState *pstate,
+ IndexTuple tuple, bool finaltup,
bool requiredMatchedByPrecheck);
extern void _bt_killitems(IndexScanDesc scan);
extern BTCycleId _bt_vacuum_cycleid(Relation rel);
diff --git a/src/backend/access/nbtree/nbtree.c b/src/backend/access/nbtree/nbtree.c
index a88b36a58..6328a8a63 100644
--- a/src/backend/access/nbtree/nbtree.c
+++ b/src/backend/access/nbtree/nbtree.c
@@ -48,8 +48,8 @@
* BTPARALLEL_IDLE indicates that no backend is currently advancing the scan
* to a new page; some process can start doing that.
*
- * BTPARALLEL_DONE indicates that the scan is complete (including error exit).
- * We reach this state once for every distinct combination of array keys.
+ * BTPARALLEL_DONE indicates that the primitive index scan is complete
+ * (including error exit). Reached once per primitive index scan.
*/
typedef enum
{
@@ -69,8 +69,8 @@ typedef struct BTParallelScanDescData
BTPS_State btps_pageStatus; /* indicates whether next page is
* available for scan. see above for
* possible states of parallel scan. */
- int btps_arrayKeyCount; /* count indicating number of array scan
- * keys processed by parallel scan */
+ int btps_numPrimScans; /* count indicating number of primitive
+ * index scans (used with array keys) */
slock_t btps_mutex; /* protects above variables */
ConditionVariable btps_cv; /* used to synchronize parallel scan */
} BTParallelScanDescData;
@@ -275,8 +275,8 @@ btgettuple(IndexScanDesc scan, ScanDirection dir)
/* If we have a tuple, return it ... */
if (res)
break;
- /* ... otherwise see if we have more array keys to deal with */
- } while (so->numArrayKeys && _bt_advance_array_keys(scan, dir));
+ /* ... otherwise see if we need another primitive index scan */
+ } while (so->numArrayKeys && _bt_array_keys_remain(scan, dir));
return res;
}
@@ -333,8 +333,8 @@ btgetbitmap(IndexScanDesc scan, TIDBitmap *tbm)
ntids++;
}
}
- /* Now see if we have more array keys to deal with */
- } while (so->numArrayKeys && _bt_advance_array_keys(scan, ForwardScanDirection));
+ /* Now see if we need another primitive index scan */
+ } while (so->numArrayKeys && _bt_array_keys_remain(scan, ForwardScanDirection));
return ntids;
}
@@ -364,9 +364,10 @@ btbeginscan(Relation rel, int nkeys, int norderbys)
so->keyData = NULL;
so->arrayKeyData = NULL; /* assume no array keys for now */
- so->arraysStarted = false;
so->numArrayKeys = 0;
+ so->needPrimScan = false;
so->arrayKeys = NULL;
+ so->orderProcs = NULL;
so->arrayContext = NULL;
so->killedItems = NULL; /* until needed */
@@ -406,7 +407,8 @@ btrescan(IndexScanDesc scan, ScanKey scankey, int nscankeys,
}
so->markItemIndex = -1;
- so->arrayKeyCount = 0;
+ so->needPrimScan = false;
+ so->numPrimScans = 0;
so->firstPage = false;
BTScanPosUnpinIfPinned(so->markPos);
BTScanPosInvalidate(so->markPos);
@@ -588,7 +590,7 @@ btinitparallelscan(void *target)
SpinLockInit(&bt_target->btps_mutex);
bt_target->btps_scanPage = InvalidBlockNumber;
bt_target->btps_pageStatus = BTPARALLEL_NOT_INITIALIZED;
- bt_target->btps_arrayKeyCount = 0;
+ bt_target->btps_numPrimScans = 0;
ConditionVariableInit(&bt_target->btps_cv);
}
@@ -614,7 +616,7 @@ btparallelrescan(IndexScanDesc scan)
SpinLockAcquire(&btscan->btps_mutex);
btscan->btps_scanPage = InvalidBlockNumber;
btscan->btps_pageStatus = BTPARALLEL_NOT_INITIALIZED;
- btscan->btps_arrayKeyCount = 0;
+ btscan->btps_numPrimScans = 0;
SpinLockRelease(&btscan->btps_mutex);
}
@@ -625,7 +627,11 @@ btparallelrescan(IndexScanDesc scan)
*
* The return value is true if we successfully seized the scan and false
* if we did not. The latter case occurs if no pages remain for the current
- * set of scankeys.
+ * primitive index scan.
+ *
+ * When array scan keys are in use, each worker process independently advances
+ * its array keys. It's crucial that each worker process never be allowed to
+ * scan a page from before the current scan position.
*
* If the return value is true, *pageno returns the next or current page
* of the scan (depending on the scan direction). An invalid block number
@@ -656,16 +662,17 @@ _bt_parallel_seize(IndexScanDesc scan, BlockNumber *pageno)
SpinLockAcquire(&btscan->btps_mutex);
pageStatus = btscan->btps_pageStatus;
- if (so->arrayKeyCount < btscan->btps_arrayKeyCount)
+ if (so->numPrimScans < btscan->btps_numPrimScans)
{
- /* Parallel scan has already advanced to a new set of scankeys. */
+ /* Top-level scan already moved on to next primitive index scan */
status = false;
}
else if (pageStatus == BTPARALLEL_DONE)
{
/*
- * We're done with this set of scankeys. This may be the end, or
- * there could be more sets to try.
+ * We're done with this primitive index scan. This might have
+ * been the final primitive index scan required, or the top-level
+ * index scan might require additional primitive scans.
*/
status = false;
}
@@ -697,9 +704,12 @@ _bt_parallel_seize(IndexScanDesc scan, BlockNumber *pageno)
void
_bt_parallel_release(IndexScanDesc scan, BlockNumber scan_page)
{
+ BTScanOpaque so PG_USED_FOR_ASSERTS_ONLY = (BTScanOpaque) scan->opaque;
ParallelIndexScanDesc parallel_scan = scan->parallel_scan;
BTParallelScanDesc btscan;
+ Assert(!so->needPrimScan);
+
btscan = (BTParallelScanDesc) OffsetToPointer((void *) parallel_scan,
parallel_scan->ps_offset);
@@ -733,12 +743,11 @@ _bt_parallel_done(IndexScanDesc scan)
parallel_scan->ps_offset);
/*
- * Mark the parallel scan as done for this combination of scan keys,
- * unless some other process already did so. See also
- * _bt_advance_array_keys.
+ * Mark the primitive index scan as done, unless some other process
+ * already did so. See also _bt_array_keys_remain.
*/
SpinLockAcquire(&btscan->btps_mutex);
- if (so->arrayKeyCount >= btscan->btps_arrayKeyCount &&
+ if (so->numPrimScans >= btscan->btps_numPrimScans &&
btscan->btps_pageStatus != BTPARALLEL_DONE)
{
btscan->btps_pageStatus = BTPARALLEL_DONE;
@@ -752,14 +761,14 @@ _bt_parallel_done(IndexScanDesc scan)
}
/*
- * _bt_parallel_advance_array_keys() -- Advances the parallel scan for array
- * keys.
+ * _bt_parallel_next_primitive_scan() -- Advances parallel primitive scan
+ * counter when array keys are in use.
*
- * Updates the count of array keys processed for both local and parallel
+ * Updates the count of primitive index scans for both local and parallel
* scans.
*/
void
-_bt_parallel_advance_array_keys(IndexScanDesc scan)
+_bt_parallel_next_primitive_scan(IndexScanDesc scan)
{
BTScanOpaque so = (BTScanOpaque) scan->opaque;
ParallelIndexScanDesc parallel_scan = scan->parallel_scan;
@@ -768,13 +777,13 @@ _bt_parallel_advance_array_keys(IndexScanDesc scan)
btscan = (BTParallelScanDesc) OffsetToPointer((void *) parallel_scan,
parallel_scan->ps_offset);
- so->arrayKeyCount++;
+ so->numPrimScans++;
SpinLockAcquire(&btscan->btps_mutex);
if (btscan->btps_pageStatus == BTPARALLEL_DONE)
{
btscan->btps_scanPage = InvalidBlockNumber;
btscan->btps_pageStatus = BTPARALLEL_NOT_INITIALIZED;
- btscan->btps_arrayKeyCount++;
+ btscan->btps_numPrimScans++;
}
SpinLockRelease(&btscan->btps_mutex);
}
diff --git a/src/backend/access/nbtree/nbtsearch.c b/src/backend/access/nbtree/nbtsearch.c
index efc5284e5..b2addd714 100644
--- a/src/backend/access/nbtree/nbtsearch.c
+++ b/src/backend/access/nbtree/nbtsearch.c
@@ -893,7 +893,7 @@ _bt_first(IndexScanDesc scan, ScanDirection dir)
*/
if (!so->qual_ok)
{
- /* Notify any other workers that we're done with this scan key. */
+ /* Notify any other workers that this primitive scan is done */
_bt_parallel_done(scan);
return false;
}
@@ -952,6 +952,10 @@ _bt_first(IndexScanDesc scan, ScanDirection dir)
* one we use --- by definition, they are either redundant or
* contradictory.
*
+ * When SK_SEARCHARRAY keys are in use, _bt_tuple_before_array_keys is
+ * used to avoid prematurely stopping the scan when an array equality qual
+ * has its array keys advanced.
+ *
* Any regular (not SK_SEARCHNULL) key implies a NOT NULL qualifier.
* If the index stores nulls at the end of the index we'll be starting
* from, and we have no boundary key for the column (which means the key
@@ -1537,9 +1541,8 @@ _bt_readpage(IndexScanDesc scan, ScanDirection dir, OffsetNumber offnum)
BTPageOpaque opaque;
OffsetNumber minoff;
OffsetNumber maxoff;
+ BTReadPageState pstate;
int itemIndex;
- bool continuescan;
- int indnatts;
bool requiredMatchedByPrecheck;
/*
@@ -1560,8 +1563,11 @@ _bt_readpage(IndexScanDesc scan, ScanDirection dir, OffsetNumber offnum)
_bt_parallel_release(scan, BufferGetBlockNumber(so->currPos.buf));
}
- continuescan = true; /* default assumption */
- indnatts = IndexRelationGetNumberOfAttributes(scan->indexRelation);
+ pstate.dir = dir;
+ pstate.finaltup = NULL;
+ pstate.continuescan = true; /* default assumption */
+ pstate.finaltupchecked = false;
+
minoff = P_FIRSTDATAKEY(opaque);
maxoff = PageGetMaxOffsetNumber(page);
@@ -1609,9 +1615,11 @@ _bt_readpage(IndexScanDesc scan, ScanDirection dir, OffsetNumber offnum)
* the last item on the page would give a more precise answer.
*
* We skip this for the first page in the scan to evade the possible
- * slowdown of the point queries.
+ * slowdown of the point queries. Do the same with scans with array keys,
+ * since that makes the optimization unsafe (our search-type scan keys can
+ * change during any call to _bt_checkkeys whenever array keys are used).
*/
- if (!so->firstPage && minoff < maxoff)
+ if (!so->firstPage && minoff < maxoff && !so->numArrayKeys)
{
ItemId iid;
IndexTuple itup;
@@ -1625,8 +1633,9 @@ _bt_readpage(IndexScanDesc scan, ScanDirection dir, OffsetNumber offnum)
* set flag to true if all required keys are satisfied and false
* otherwise.
*/
- (void) _bt_checkkeys(scan, itup, indnatts, dir,
- &requiredMatchedByPrecheck, false);
+ _bt_checkkeys(scan, &pstate, itup, false, false);
+ requiredMatchedByPrecheck = pstate.continuescan;
+ pstate.continuescan = true; /* reset */
}
else
{
@@ -1636,6 +1645,14 @@ _bt_readpage(IndexScanDesc scan, ScanDirection dir, OffsetNumber offnum)
if (ScanDirectionIsForward(dir))
{
+ /* SK_SEARCHARRAY forward scans must provide high key up front */
+ if (so->numArrayKeys && !P_RIGHTMOST(opaque))
+ {
+ ItemId iid = PageGetItemId(page, P_HIKEY);
+
+ pstate.finaltup = (IndexTuple) PageGetItem(page, iid);
+ }
+
/* load items[] in ascending order */
itemIndex = 0;
@@ -1659,8 +1676,8 @@ _bt_readpage(IndexScanDesc scan, ScanDirection dir, OffsetNumber offnum)
itup = (IndexTuple) PageGetItem(page, iid);
- passes_quals = _bt_checkkeys(scan, itup, indnatts, dir,
- &continuescan, requiredMatchedByPrecheck);
+ passes_quals = _bt_checkkeys(scan, &pstate, itup, false,
+ requiredMatchedByPrecheck);
/*
* If the result of prechecking required keys was true, then in
@@ -1668,8 +1685,8 @@ _bt_readpage(IndexScanDesc scan, ScanDirection dir, OffsetNumber offnum)
* result is the same.
*/
Assert(!requiredMatchedByPrecheck ||
- passes_quals == _bt_checkkeys(scan, itup, indnatts, dir,
- &continuescan, false));
+ passes_quals == _bt_checkkeys(scan, &pstate, itup, false,
+ false));
if (passes_quals)
{
/* tuple passes all scan key conditions */
@@ -1703,7 +1720,7 @@ _bt_readpage(IndexScanDesc scan, ScanDirection dir, OffsetNumber offnum)
}
}
/* When !continuescan, there can't be any more matches, so stop */
- if (!continuescan)
+ if (!pstate.continuescan)
break;
offnum = OffsetNumberNext(offnum);
@@ -1720,17 +1737,23 @@ _bt_readpage(IndexScanDesc scan, ScanDirection dir, OffsetNumber offnum)
* only appear on non-pivot tuples on the right sibling page are
* common.
*/
- if (continuescan && !P_RIGHTMOST(opaque))
+ if (pstate.continuescan && !P_RIGHTMOST(opaque))
{
- ItemId iid = PageGetItemId(page, P_HIKEY);
- IndexTuple itup = (IndexTuple) PageGetItem(page, iid);
- int truncatt;
+ IndexTuple itup;
- truncatt = BTreeTupleGetNAtts(itup, scan->indexRelation);
- _bt_checkkeys(scan, itup, truncatt, dir, &continuescan, false);
+ if (pstate.finaltup)
+ itup = pstate.finaltup;
+ else
+ {
+ ItemId iid = PageGetItemId(page, P_HIKEY);
+
+ itup = (IndexTuple) PageGetItem(page, iid);
+ }
+
+ _bt_checkkeys(scan, &pstate, itup, true, false);
}
- if (!continuescan)
+ if (!pstate.continuescan)
so->currPos.moreRight = false;
Assert(itemIndex <= MaxTIDsPerBTreePage);
@@ -1740,6 +1763,14 @@ _bt_readpage(IndexScanDesc scan, ScanDirection dir, OffsetNumber offnum)
}
else
{
+ /* SK_SEARCHARRAY backward scans must provide final tuple up front */
+ if (so->numArrayKeys && minoff < maxoff)
+ {
+ ItemId iid = PageGetItemId(page, minoff);
+
+ pstate.finaltup = (IndexTuple) PageGetItem(page, iid);
+ }
+
/* load items[] in descending order */
itemIndex = MaxTIDsPerBTreePage;
@@ -1751,6 +1782,7 @@ _bt_readpage(IndexScanDesc scan, ScanDirection dir, OffsetNumber offnum)
IndexTuple itup;
bool tuple_alive;
bool passes_quals;
+ bool finaltup = (offnum == minoff);
/*
* If the scan specifies not to return killed tuples, then we
@@ -1761,12 +1793,18 @@ _bt_readpage(IndexScanDesc scan, ScanDirection dir, OffsetNumber offnum)
* tuple on the page, we do check the index keys, to prevent
* uselessly advancing to the page to the left. This is similar
* to the high key optimization used by forward scans.
+ *
+ * Separately, _bt_checkkeys actually requires that we call it
+ * with the final non-pivot tuple from the page, if there's one
+ * (final processed tuple, or first tuple in offset number terms).
+ * We must indicate which particular tuple comes last, too.
*/
if (scan->ignore_killed_tuples && ItemIdIsDead(iid))
{
Assert(offnum >= P_FIRSTDATAKEY(opaque));
- if (offnum > P_FIRSTDATAKEY(opaque))
+ if (!finaltup)
{
+ Assert(offnum > minoff);
offnum = OffsetNumberPrev(offnum);
continue;
}
@@ -1778,8 +1816,8 @@ _bt_readpage(IndexScanDesc scan, ScanDirection dir, OffsetNumber offnum)
itup = (IndexTuple) PageGetItem(page, iid);
- passes_quals = _bt_checkkeys(scan, itup, indnatts, dir,
- &continuescan, requiredMatchedByPrecheck);
+ passes_quals = _bt_checkkeys(scan, &pstate, itup, finaltup,
+ requiredMatchedByPrecheck);
/*
* If the result of prechecking required keys was true, then in
@@ -1787,8 +1825,8 @@ _bt_readpage(IndexScanDesc scan, ScanDirection dir, OffsetNumber offnum)
* result is the same.
*/
Assert(!requiredMatchedByPrecheck ||
- passes_quals == _bt_checkkeys(scan, itup, indnatts, dir,
- &continuescan, false));
+ passes_quals == _bt_checkkeys(scan, &pstate, itup,
+ finaltup, false));
if (passes_quals && tuple_alive)
{
/* tuple passes all scan key conditions */
@@ -1827,7 +1865,7 @@ _bt_readpage(IndexScanDesc scan, ScanDirection dir, OffsetNumber offnum)
}
}
}
- if (!continuescan)
+ if (!pstate.continuescan)
{
/* there can't be any more matches, so stop */
so->currPos.moreLeft = false;
diff --git a/src/backend/access/nbtree/nbtutils.c b/src/backend/access/nbtree/nbtutils.c
index 1510b97fb..8318e6250 100644
--- a/src/backend/access/nbtree/nbtutils.c
+++ b/src/backend/access/nbtree/nbtutils.c
@@ -33,7 +33,7 @@
typedef struct BTSortArrayContext
{
- FmgrInfo flinfo;
+ FmgrInfo *orderproc;
Oid collation;
bool reverse;
} BTSortArrayContext;
@@ -41,15 +41,41 @@ typedef struct BTSortArrayContext
static Datum _bt_find_extreme_element(IndexScanDesc scan, ScanKey skey,
StrategyNumber strat,
Datum *elems, int nelems);
+static void _bt_sort_cmp_func_setup(IndexScanDesc scan, ScanKey skey);
static int _bt_sort_array_elements(IndexScanDesc scan, ScanKey skey,
bool reverse,
Datum *elems, int nelems);
+static int _bt_merge_arrays(IndexScanDesc scan, ScanKey skey, bool reverse,
+ Datum *elems_orig, int nelems_orig,
+ Datum *elems_next, int nelems_next);
static int _bt_compare_array_elements(const void *a, const void *b, void *arg);
+static inline int32 _bt_compare_array_skey(FmgrInfo *orderproc,
+ Datum tupdatum, bool tupnull,
+ Datum arrdatum, ScanKey cur);
+static int _bt_binsrch_array_skey(FmgrInfo *orderproc,
+ bool cur_elem_start, ScanDirection dir,
+ Datum tupdatum, bool tupnull,
+ BTArrayKeyInfo *array, ScanKey cur,
+ int32 *final_result);
+static bool _bt_advance_array_keys_increment(IndexScanDesc scan, ScanDirection dir);
+static bool _bt_tuple_before_array_skeys(IndexScanDesc scan,
+ BTReadPageState *pstate,
+ IndexTuple tuple);
+static bool _bt_advance_array_keys(IndexScanDesc scan, BTReadPageState *pstate,
+ IndexTuple tuple, bool skrequiredtrigger);
+static void _bt_preprocess_keys_leafbuf(IndexScanDesc scan);
+#ifdef USE_ASSERT_CHECKING
+static bool _bt_verify_array_scankeys(IndexScanDesc scan);
+#endif
static bool _bt_compare_scankey_args(IndexScanDesc scan, ScanKey op,
ScanKey leftarg, ScanKey rightarg,
bool *result);
static bool _bt_fix_scankey_strategy(ScanKey skey, int16 *indoption);
static void _bt_mark_scankey_required(ScanKey skey);
+static bool _bt_check_compare(ScanDirection dir, BTScanOpaque so,
+ IndexTuple tuple, int tupnatts, TupleDesc tupdesc,
+ bool *continuescan, bool *skrequiredtrigger,
+ bool requiredMatchedByPrecheck);
static bool _bt_check_rowcompare(ScanKey skey,
IndexTuple tuple, int tupnatts, TupleDesc tupdesc,
ScanDirection dir, bool *continuescan);
@@ -198,13 +224,48 @@ _bt_freestack(BTStack stack)
* If there are any SK_SEARCHARRAY scan keys, deconstruct the array(s) and
* set up BTArrayKeyInfo info for each one that is an equality-type key.
* Prepare modified scan keys in so->arrayKeyData, which will hold the current
- * array elements during each primitive indexscan operation. For inequality
- * array keys, it's sufficient to find the extreme element value and replace
- * the whole array with that scalar value.
+ * array elements.
+ *
+ * _bt_preprocess_keys treats each primitive scan as an independent piece of
+ * work. That structure pushes the responsibility for preprocessing that must
+ * work "across array keys" onto us. This division of labor makes sense once
+ * you consider that we're typically called no more than once per btrescan,
+ * whereas _bt_preprocess_keys is always called once per primitive index scan.
+ *
+ * Currently we perform two kinds of preprocessing to deal with redundancies.
+ * For inequality array keys, it's sufficient to find the extreme element
+ * value and replace the whole array with that scalar value. This eliminates
+ * all but one array key as redundant. Similarly, we are capable of "merging
+ * together" multiple equality array keys from two or more input scan keys
+ * into a single output scan key that contains only the intersecting array
+ * elements. This can eliminate many redundant array elements, as well as
+ * eliminating whole array scan keys as redundant.
+ *
+ * Note: _bt_start_array_keys actually sets up the cur_elem counters later on,
+ * once the scan direction is known.
*
* Note: the reason we need so->arrayKeyData, rather than just scribbling
* on scan->keyData, is that callers are permitted to call btrescan without
* supplying a new set of scankey data.
+ *
+ * Note: _bt_preprocess_keys is responsible for creating the so->keyData scan
+ * keys used by _bt_checkkeys. Index scans that don't use equality array keys
+ * will have _bt_preprocess_keys treat scan->keyData as input and so->keyData
+ * as output. Scans that use equality array keys have _bt_preprocess_keys
+ * treat so->arrayKeyData (which is our output) as their input, while (as per
+ * usual) outputting so->keyData for _bt_checkkeys. This function adds an
+ * additional layer of indirection that allows _bt_preprocess_keys to more or
+ * less avoid dealing with SK_SEARCHARRAY as a special case.
+ *
+ * Note: _bt_preprocess_keys_leafbuf works by updating already-processed
+ * output keys (so->keyData) in-place. It cannot eliminate redundant or
+ * contradictory scan keys. This necessitates having _bt_preprocess_keys
+ * understand that it is unsafe to eliminate "redundant" SK_SEARCHARRAY
+ * equality scan keys on the basis of what is actually just the current array
+ * key values -- it must conservatively assume that such a scan key might no
+ * longer be redundant after the next _bt_preprocess_keys_leafbuf call.
+ * Ideally we'd be able to deal with that by eliminating a subset of truly
+ * redundant array keys up-front, but it doesn't seem worth the trouble.
*/
void
_bt_preprocess_array_keys(IndexScanDesc scan)
@@ -212,7 +273,9 @@ _bt_preprocess_array_keys(IndexScanDesc scan)
BTScanOpaque so = (BTScanOpaque) scan->opaque;
int numberOfKeys = scan->numberOfKeys;
int16 *indoption = scan->indexRelation->rd_indoption;
+ int16 nkeyatts = IndexRelationGetNumberOfKeyAttributes(scan->indexRelation);
int numArrayKeys;
+ int lastEqualityArrayAtt = -1;
ScanKey cur;
int i;
MemoryContext oldContext;
@@ -265,6 +328,7 @@ _bt_preprocess_array_keys(IndexScanDesc scan)
/* Allocate space for per-array data in the workspace context */
so->arrayKeys = (BTArrayKeyInfo *) palloc0(numArrayKeys * sizeof(BTArrayKeyInfo));
+ so->orderProcs = (FmgrInfo *) palloc0(nkeyatts * sizeof(FmgrInfo));
/* Now process each array key */
numArrayKeys = 0;
@@ -281,6 +345,16 @@ _bt_preprocess_array_keys(IndexScanDesc scan)
int j;
cur = &so->arrayKeyData[i];
+
+ /*
+ * Attributes with equality-type scan keys (including but not limited
+ * to array scan keys) will need a 3-way comparison function. Set
+ * that up now. (Avoids repeating work for the same attribute.)
+ */
+ if (cur->sk_strategy == BTEqualStrategyNumber &&
+ !OidIsValid(so->orderProcs[cur->sk_attno - 1].fn_oid))
+ _bt_sort_cmp_func_setup(scan, cur);
+
if (!(cur->sk_flags & SK_SEARCHARRAY))
continue;
@@ -357,6 +431,46 @@ _bt_preprocess_array_keys(IndexScanDesc scan)
(indoption[cur->sk_attno - 1] & INDOPTION_DESC) != 0,
elem_values, num_nonnulls);
+ /*
+ * If this scan key is semantically equivalent to a previous equality
+ * operator array scan key, merge the two arrays together to eliminate
+ * redundant non-intersecting elements (and redundant whole scan keys)
+ */
+ if (lastEqualityArrayAtt == cur->sk_attno)
+ {
+ BTArrayKeyInfo *prev = &so->arrayKeys[numArrayKeys - 1];
+
+ Assert(so->arrayKeyData[prev->scan_key].sk_func.fn_oid ==
+ cur->sk_func.fn_oid);
+ Assert(so->arrayKeyData[prev->scan_key].sk_subtype ==
+ cur->sk_subtype);
+
+ /* We could pfree(elem_values) after, but not worth the cycles */
+ num_elems = _bt_merge_arrays(scan, cur,
+ (indoption[cur->sk_attno - 1] & INDOPTION_DESC) != 0,
+ prev->elem_values, prev->num_elems,
+ elem_values, num_elems);
+
+ /*
+ * If there are no intersecting elements left from merging this
+ * array into the previous array on the same attribute, the scan
+ * qual is unsatisfiable
+ */
+ if (num_elems == 0)
+ {
+ numArrayKeys = -1;
+ break;
+ }
+
+ /*
+ * Lower the number of elements from the previous array, and mark
+ * this scan key/array as redundant for every primitive index scan
+ */
+ prev->num_elems = num_elems;
+ cur->sk_flags |= SK_BT_RDDNARRAY;
+ continue;
+ }
+
/*
* And set up the BTArrayKeyInfo data.
*/
@@ -364,6 +478,7 @@ _bt_preprocess_array_keys(IndexScanDesc scan)
so->arrayKeys[numArrayKeys].num_elems = num_elems;
so->arrayKeys[numArrayKeys].elem_values = elem_values;
numArrayKeys++;
+ lastEqualityArrayAtt = cur->sk_attno;
}
so->numArrayKeys = numArrayKeys;
@@ -437,26 +552,20 @@ _bt_find_extreme_element(IndexScanDesc scan, ScanKey skey,
}
/*
- * _bt_sort_array_elements() -- sort and de-dup array elements
+ * Look up the appropriate comparison function in the opfamily.
*
- * The array elements are sorted in-place, and the new number of elements
- * after duplicate removal is returned.
- *
- * scan and skey identify the index column, whose opfamily determines the
- * comparison semantics. If reverse is true, we sort in descending order.
+ * Note: it's possible that this would fail, if the opfamily is incomplete,
+ * but it seems quite unlikely that an opfamily would omit non-cross-type
+ * support functions for any datatype that it supports at all.
*/
-static int
-_bt_sort_array_elements(IndexScanDesc scan, ScanKey skey,
- bool reverse,
- Datum *elems, int nelems)
+static void
+_bt_sort_cmp_func_setup(IndexScanDesc scan, ScanKey skey)
{
+ BTScanOpaque so = (BTScanOpaque) scan->opaque;
Relation rel = scan->indexRelation;
Oid elemtype;
RegProcedure cmp_proc;
- BTSortArrayContext cxt;
-
- if (nelems <= 1)
- return nelems; /* no work to do */
+ FmgrInfo *orderproc = &so->orderProcs[skey->sk_attno - 1];
/*
* Determine the nominal datatype of the array elements. We have to
@@ -471,12 +580,10 @@ _bt_sort_array_elements(IndexScanDesc scan, ScanKey skey,
* Look up the appropriate comparison function in the opfamily.
*
* Note: it's possible that this would fail, if the opfamily is
- * incomplete, but it seems quite unlikely that an opfamily would omit
- * non-cross-type support functions for any datatype that it supports at
- * all.
+ * incomplete.
*/
cmp_proc = get_opfamily_proc(rel->rd_opfamily[skey->sk_attno - 1],
- elemtype,
+ rel->rd_opcintype[skey->sk_attno - 1],
elemtype,
BTORDER_PROC);
if (!RegProcedureIsValid(cmp_proc))
@@ -484,8 +591,32 @@ _bt_sort_array_elements(IndexScanDesc scan, ScanKey skey,
BTORDER_PROC, elemtype, elemtype,
rel->rd_opfamily[skey->sk_attno - 1]);
+ /* Save in orderproc entry for attribute */
+ fmgr_info_cxt(cmp_proc, orderproc, so->arrayContext);
+}
+
+/*
+ * _bt_sort_array_elements() -- sort and de-dup array elements
+ *
+ * The array elements are sorted in-place, and the new number of elements
+ * after duplicate removal is returned.
+ *
+ * scan and skey identify the index column, whose opfamily determines the
+ * comparison semantics. If reverse is true, we sort in descending order.
+ */
+static int
+_bt_sort_array_elements(IndexScanDesc scan, ScanKey skey,
+ bool reverse,
+ Datum *elems, int nelems)
+{
+ BTScanOpaque so = (BTScanOpaque) scan->opaque;
+ BTSortArrayContext cxt;
+
+ if (nelems <= 1)
+ return nelems; /* no work to do */
+
/* Sort the array elements */
- fmgr_info(cmp_proc, &cxt.flinfo);
+ cxt.orderproc = &so->orderProcs[skey->sk_attno - 1];
cxt.collation = skey->sk_collation;
cxt.reverse = reverse;
qsort_arg(elems, nelems, sizeof(Datum),
@@ -496,6 +627,48 @@ _bt_sort_array_elements(IndexScanDesc scan, ScanKey skey,
_bt_compare_array_elements, &cxt);
}
+/*
+ * _bt_merge_arrays() -- merge together duplicate array keys
+ *
+ * Both scan key's have array elements that have already been sorted and
+ * deduplicated.
+ */
+static int
+_bt_merge_arrays(IndexScanDesc scan, ScanKey skey, bool reverse,
+ Datum *elems_orig, int nelems_orig,
+ Datum *elems_next, int nelems_next)
+{
+ BTScanOpaque so = (BTScanOpaque) scan->opaque;
+ BTSortArrayContext cxt;
+ Datum *merged = palloc(sizeof(Datum) * nelems_orig);
+ int merged_nelems = 0;
+
+ /*
+ * Incrementally copy the original array into a temp buffer, skipping over
+ * any items that are missing from the "next" array
+ */
+ cxt.orderproc = &so->orderProcs[skey->sk_attno - 1];
+ cxt.collation = skey->sk_collation;
+ cxt.reverse = reverse;
+ for (int i = 0; i < nelems_orig; i++)
+ {
+ Datum *elem = elems_orig + i;
+
+ if (bsearch_arg(elem, elems_next, nelems_next, sizeof(Datum),
+ _bt_compare_array_elements, &cxt))
+ merged[merged_nelems++] = *elem;
+ }
+
+ /*
+ * Overwrite the original array with temp buffer so that we're only left
+ * with intersecting array elements
+ */
+ memcpy(elems_orig, merged, merged_nelems * sizeof(Datum));
+ pfree(merged);
+
+ return merged_nelems;
+}
+
/*
* qsort_arg comparator for sorting array elements
*/
@@ -507,7 +680,7 @@ _bt_compare_array_elements(const void *a, const void *b, void *arg)
BTSortArrayContext *cxt = (BTSortArrayContext *) arg;
int32 compare;
- compare = DatumGetInt32(FunctionCall2Coll(&cxt->flinfo,
+ compare = DatumGetInt32(FunctionCall2Coll(cxt->orderproc,
cxt->collation,
da, db));
if (cxt->reverse)
@@ -515,6 +688,161 @@ _bt_compare_array_elements(const void *a, const void *b, void *arg)
return compare;
}
+/*
+ * Comparator uses to search for the next array element when array keys need
+ * to be advanced via one or more binary searches
+ *
+ * This routine returns:
+ * <0 if tupdatum < arrdatum;
+ * 0 if tupdatum == arrdatum;
+ * >0 if tupdatum > arrdatum.
+ *
+ * This is essentially the same interface as _bt_compare: both functions
+ * compare the value that they're searching for to a binary search pivot.
+ * However, unlike _bt_compare, this function's "tuple argument" comes first,
+ * while its "array/scankey argument" comes second.
+*/
+static inline int32
+_bt_compare_array_skey(FmgrInfo *orderproc,
+ Datum tupdatum, bool tupnull,
+ Datum arrdatum, ScanKey cur)
+{
+ int32 result = 0;
+
+ Assert(cur->sk_strategy == BTEqualStrategyNumber);
+ Assert((cur->sk_flags & SK_ROW_HEADER) == 0);
+
+ if (cur->sk_flags & SK_ISNULL) /* array/scan key is NULL */
+ {
+ if (tupnull)
+ result = 0; /* NULL "=" NULL */
+ else if (cur->sk_flags & SK_BT_NULLS_FIRST)
+ result = 1; /* NULL "<" NOT_NULL */
+ else
+ result = -1; /* NULL ">" NOT_NULL */
+ }
+ else if (tupnull) /* array/scan key is NOT_NULL and tuple item
+ * is NULL */
+ {
+ if (cur->sk_flags & SK_BT_NULLS_FIRST)
+ result = -1; /* NOT_NULL ">" NULL */
+ else
+ result = 1; /* NOT_NULL "<" NULL */
+ }
+ else
+ {
+ /*
+ * Like _bt_compare, we need to be careful of cross-type comparisons,
+ * so the left value has to be the value that came from an index
+ * tuple. (Array scan keys cannot be cross-type, but other required
+ * scan keys that use an equal operator can be.)
+ */
+ result = DatumGetInt32(FunctionCall2Coll(orderproc, cur->sk_collation,
+ tupdatum, arrdatum));
+
+ /*
+ * Unlike _bt_compare, we flip the sign when column is a DESC column
+ * (and *not* when column is ASC). This matches the approach taken by
+ * _bt_check_rowcompare, which performs similar three-way comparisons.
+ */
+ if (cur->sk_flags & SK_BT_DESC)
+ INVERT_COMPARE_RESULT(result);
+ }
+
+ return result;
+}
+
+/*
+ * _bt_binsrch_array_skey() -- Binary search for next matching array key
+ *
+ * cur_elem_start indicates if the binary search should begin at the array's
+ * current element (or have the current element as an upper bound if it's a
+ * backward scan). This (and information about the scan's direction) allows
+ * searches against required scan key arrays to reuse earlier search bounds as
+ * an optimization.
+ *
+ * Returns an index to the first array element >= caller's tupdatum argument.
+ * Also sets *final_result to whatever _bt_compare_array_skey returned when we
+ * directly compared the returned array element to caller's tupdatum argument.
+ */
+static int
+_bt_binsrch_array_skey(FmgrInfo *orderproc,
+ bool cur_elem_start, ScanDirection dir,
+ Datum tupdatum, bool tupnull,
+ BTArrayKeyInfo *array, ScanKey cur,
+ int32 *final_result)
+{
+ int low_elem,
+ mid_elem,
+ high_elem,
+ result = 0;
+
+ Assert(cur->sk_flags & SK_SEARCHARRAY);
+ Assert(cur->sk_strategy == BTEqualStrategyNumber);
+ Assert(!cur_elem_start ||
+ array->elem_values[array->cur_elem] == cur->sk_argument);
+
+ if (ScanDirectionIsForward(dir))
+ {
+ if (cur_elem_start)
+ low_elem = array->cur_elem;
+ else
+ low_elem = 0;
+ high_elem = array->num_elems - 1;
+ }
+ else
+ {
+ low_elem = 0;
+ if (cur_elem_start)
+ high_elem = array->cur_elem;
+ else
+ high_elem = array->num_elems - 1;
+ }
+ mid_elem = -1;
+
+ while (high_elem > low_elem)
+ {
+ Datum arrdatum;
+
+ mid_elem = low_elem + ((high_elem - low_elem) / 2);
+ arrdatum = array->elem_values[mid_elem];
+
+ result = _bt_compare_array_skey(orderproc, tupdatum, tupnull,
+ arrdatum, cur);
+
+ if (result == 0)
+ {
+ /*
+ * Each array was deduplicated during initial preprocessing, so
+ * it's safe to quit as soon as we see an equal array element.
+ * This often saves an extra comparison or two...
+ */
+ low_elem = mid_elem;
+ break;
+ }
+
+ if (result > 0)
+ low_elem = mid_elem + 1;
+ else
+ high_elem = mid_elem;
+ }
+
+ /*
+ * ...but our caller also cares about how its searched-for tuple datum
+ * compares to the array element we'll return. We set *final_result with
+ * the result of that comparison specifically.
+ *
+ * Avoid setting *final_result to the wrong comparison's result.
+ */
+ if (low_elem != mid_elem)
+ result = _bt_compare_array_skey(orderproc, tupdatum, tupnull,
+ array->elem_values[low_elem], cur);
+
+ *final_result = result;
+
+ return low_elem;
+}
+
/*
* _bt_start_array_keys() -- Initialize array keys at start of a scan
*
@@ -539,30 +867,35 @@ _bt_start_array_keys(IndexScanDesc scan, ScanDirection dir)
curArrayKey->cur_elem = 0;
skey->sk_argument = curArrayKey->elem_values[curArrayKey->cur_elem];
}
-
- so->arraysStarted = true;
}
/*
- * _bt_advance_array_keys() -- Advance to next set of array elements
+ * _bt_advance_array_keys_increment() -- Advance to next set of array elements
+ *
+ * Advances the array keys by a single increment in the current scan
+ * direction. When there are multiple array keys this can roll over from the
+ * lowest order array to higher order arrays.
*
* Returns true if there is another set of values to consider, false if not.
* On true result, the scankeys are initialized with the next set of values.
+ * On false result, the scankeys stay the same, and the array keys are not
+ * advanced (every array is still at its final element for scan direction).
*/
-bool
-_bt_advance_array_keys(IndexScanDesc scan, ScanDirection dir)
+static bool
+_bt_advance_array_keys_increment(IndexScanDesc scan, ScanDirection dir)
{
BTScanOpaque so = (BTScanOpaque) scan->opaque;
bool found = false;
- int i;
+
+ Assert(!so->needPrimScan);
/*
* We must advance the last array key most quickly, since it will
* correspond to the lowest-order index column among the available
- * qualifications. This is necessary to ensure correct ordering of output
- * when there are multiple array keys.
+ * qualifications. Rolling over like this is necessary to ensure correct
+ * ordering of output when there are multiple array keys.
*/
- for (i = so->numArrayKeys - 1; i >= 0; i--)
+ for (int i = so->numArrayKeys - 1; i >= 0; i--)
{
BTArrayKeyInfo *curArrayKey = &so->arrayKeys[i];
ScanKey skey = &so->arrayKeyData[curArrayKey->scan_key];
@@ -596,19 +929,31 @@ _bt_advance_array_keys(IndexScanDesc scan, ScanDirection dir)
break;
}
- /* advance parallel scan */
- if (scan->parallel_scan != NULL)
- _bt_parallel_advance_array_keys(scan);
+ if (found)
+ return true;
/*
- * When no new array keys were found, the scan is "past the end" of the
- * array keys. _bt_start_array_keys can still "restart" the array keys if
- * a rescan is required.
+ * Don't allow the entire set of array keys to roll over: restore the
+ * array keys to the state they were in before we were called.
+ *
+ * This ensures that the array keys only ratchet forward (or backwards in
+ * the case of backward scans). Our "so->arrayKeyData" scan keys should
+ * always match the current "so->keyData" search-type scan keys (except
+ * for a brief moment during array key advancement).
*/
- if (!found)
- so->arraysStarted = false;
+ for (int i = 0; i < so->numArrayKeys; i++)
+ {
+ BTArrayKeyInfo *rollarray = &so->arrayKeys[i];
+ ScanKey skey = &so->arrayKeyData[rollarray->scan_key];
- return found;
+ if (ScanDirectionIsBackward(dir))
+ rollarray->cur_elem = 0;
+ else
+ rollarray->cur_elem = rollarray->num_elems - 1;
+ skey->sk_argument = rollarray->elem_values[rollarray->cur_elem];
+ }
+
+ return false;
}
/*
@@ -622,6 +967,8 @@ _bt_mark_array_keys(IndexScanDesc scan)
BTScanOpaque so = (BTScanOpaque) scan->opaque;
int i;
+ Assert(_bt_verify_array_scankeys(scan));
+
for (i = 0; i < so->numArrayKeys; i++)
{
BTArrayKeyInfo *curArrayKey = &so->arrayKeys[i];
@@ -661,20 +1008,691 @@ _bt_restore_array_keys(IndexScanDesc scan)
* If we changed any keys, we must redo _bt_preprocess_keys. That might
* sound like overkill, but in cases with multiple keys per index column
* it seems necessary to do the full set of pushups.
- *
- * Also do this whenever the scan's set of array keys "wrapped around" at
- * the end of the last primitive index scan. There won't have been a call
- * to _bt_preprocess_keys from some other place following wrap around, so
- * we do it for ourselves.
*/
- if (changed || !so->arraysStarted)
+ if (changed)
{
_bt_preprocess_keys(scan);
/* The mark should have been set on a consistent set of keys... */
Assert(so->qual_ok);
}
+
+ Assert(_bt_verify_array_scankeys(scan));
}
+/*
+ * Routine to determine if a continuescan=false tuple (set that way by an
+ * initial call to _bt_check_compare) must advance the scan's array keys.
+ * Only call here when _bt_check_compare already set continuescan=false.
+ *
+ * Returns true when caller passes a tuple that is < the current set of array
+ * keys for the most significant non-equal column/scan key (or > for backwards
+ * scans). This means that it cannot possibly be time to advance the array
+ * keys just yet. _bt_checkkeys caller should suppress its _bt_check_compare
+ * call, and return -- the tuple is treated as not satisfying our indexquals.
+ *
+ * Returns false when caller's tuple is >= the current array keys (or <=, in
+ * the case of backwards scans). This means that it is now time for our
+ * caller to advance the array keys (unless caller broke the rules by not
+ * checking with _bt_check_compare before calling here).
+ *
+ * Note: advancing the array keys may be required when every attribute value
+ * from caller's tuple is equal to corresponding scan key/array datums. See
+ * function header comments at the start of _bt_advance_array_keys for more.
+ */
+static bool
+_bt_tuple_before_array_skeys(IndexScanDesc scan, BTReadPageState *pstate,
+ IndexTuple tuple)
+{
+ BTScanOpaque so = (BTScanOpaque) scan->opaque;
+ Relation rel = scan->indexRelation;
+ ScanDirection dir = pstate->dir;
+ TupleDesc itupdesc = RelationGetDescr(rel);
+ bool tuple_before_array_keys = false;
+ ScanKey cur;
+ int ntupatts = BTreeTupleGetNAtts(tuple, rel),
+ ikey;
+
+ Assert(so->numArrayKeys > 0);
+ Assert(so->numberOfKeys > 0);
+ Assert(!so->needPrimScan);
+
+ for (cur = so->keyData, ikey = 0; ikey < so->numberOfKeys; cur++, ikey++)
+ {
+ int attnum = cur->sk_attno;
+ FmgrInfo *orderproc;
+ Datum tupdatum;
+ bool tupnull,
+ skrequired;
+ int32 result;
+
+ /*
+ * We only deal with equality strategy scan keys. We leave handling
+ * of inequalities up to _bt_check_compare.
+ */
+ if (cur->sk_strategy != BTEqualStrategyNumber)
+ continue;
+
+ /*
+ * Determine if this scan key is required.
+ *
+ * Equality strategy scan keys are either required in both directions
+ * or neither direction, so the current scan direction doesn't need to
+ * be tested here.
+ */
+ skrequired = (cur->sk_flags & SK_BT_REQFWD);
+ Assert(!skrequired || (cur->sk_flags & SK_BT_REQBKWD));
+
+ /*
+ * Unlike _bt_advance_array_keys, we never deal with any non-required
+ * array keys. Cases where skrequiredtrigger is set to false by
+ * _bt_check_compare should never call here. We are only called after
+ * _bt_check_compare provisionally indicated that the scan should be
+ * terminated due to a _required_ scan key not being satisfied.
+ *
+ * We expect _bt_check_compare to notice and report required scan keys
+ * before non-required ones. _bt_advance_array_keys might still have
+ * to advance non-required array keys in passing for a tuple that we
+ * were called for, but it doesn't need advanced notice of that from
+ * us.
+ */
+ if (!skrequired)
+ break;
+
+ if (attnum > ntupatts)
+ {
+ /*
+ * When we reach a high key's truncated attribute, assume that the
+ * tuple attribute's value is >= the scan's search-type scan keys
+ */
+ break;
+ }
+
+ tupdatum = index_getattr(tuple, attnum, itupdesc, &tupnull);
+
+ orderproc = &so->orderProcs[attnum - 1];
+ result = _bt_compare_array_skey(orderproc, tupdatum, tupnull,
+ cur->sk_argument, cur);
+
+ if (result != 0)
+ {
+ if (ScanDirectionIsForward(dir))
+ tuple_before_array_keys = result < 0;
+ else
+ tuple_before_array_keys = result > 0;
+
+ break;
+ }
+ }
+
+ return tuple_before_array_keys;
+}
+
+/*
+ * _bt_array_keys_remain() -- Start another primitive index scan?
+ *
+ * Returns true if _bt_checkkeys determined that another primitive index scan
+ * must take place by calling _bt_first. Otherwise returns false, indicating
+ * that caller's top-level scan is now past the point where further matching
+ * index tuples can be found (for the current scan direction).
+ *
+ * Only call here during scans with one or more equality type array scan keys.
+ * All other scans should just call _bt_first once, no matter what.
+ *
+ * Top-level index scans executed via multiple primitive index scans must not
+ * fail to output index tuples in the usual order for the index -- just like
+ * any other index scan would. The state machine that manages the scan's
+ * array keys must only start primitive index scans when they cover key space
+ * strictly greater than the key space for tuples that the scan has already
+ * returned (or strictly less in the backwards scan case). Otherwise the scan
+ * could output the same index tuples more than once, or in the wrong order.
+ *
+ * This is managed by limiting the cases that can trigger new primitive index
+ * scans to those involving required array scan keys and/or other required
+ * scan keys that use the equality strategy. In particular, the state machine
+ * must not allow high order required scan keys using an inequality strategy
+ * (which are only required in one scan direction) to directly trigger a new
+ * primitive index scan that advances low order non-required array scan keys.
+ * For example, a query such as "SELECT thousand, tenthous FROM tenk1 WHERE
+ * thousand < 2 AND tenthous IN (1001,3000) ORDER BY thousand" whose execution
+ * involves a scan of an index on "(thousand, tenthous)" must perform no more
+ * than a single primitive index scan. Otherwise we risk outputting tuples in
+ * the wrong order. Array key values for the non-required scan key on the
+ * "tenthous" column must not dictate top-level scan order. Primitive index
+ * scans mustn't scan tuples already scanned by some earlier primitive scan.
+ *
+ * In fact, nbtree makes a stronger guarantee than is strictly necessary here:
+ * it guarantees that the top-level scan won't repeat any leaf page reads.
+ * (Actually, that can still happen when the scan is repositioned, or the scan
+ * direction changes -- but that's just as true with other types of scans.)
+ */
+bool
+_bt_array_keys_remain(IndexScanDesc scan, ScanDirection dir)
+{
+ BTScanOpaque so = (BTScanOpaque) scan->opaque;
+
+ Assert(so->numArrayKeys);
+
+ /*
+ * Array keys are advanced within _bt_checkkeys when the scan reaches the
+ * leaf level (more precisely, they're advanced when the scan reaches the
+ * end of each distinct set of array elements). This process avoids
+ * repeat access to leaf pages (across multiple primitive index scans) by
+ * opportunistically advancing the scan's array keys when it allows the
+ * primitive index scan to find nearby matching tuples (or to eliminate
+ * array keys with no matching tuples from further consideration).
+ *
+ * _bt_checkkeys sets a simple flag variable that we check here. This
+ * tells us if we need to perform another primitive index scan for the
+ * now-current array keys or not. We'll unset the flag once again to
+ * acknowledge having started a new primitive scan (or we'll see that it
+ * isn't set and end the top-level scan right away).
+ *
+ * We cannot rely on _bt_first always reaching _bt_checkkeys here. There
+ * are various scenarios where that won't happen. For example, if the
+ * index is completely empty, then _bt_first won't get as far as calling
+ * _bt_readpage/_bt_checkkeys.
+ *
+ * We also don't expect _bt_checkkeys to be reached when searching for a
+ * non-existent value that happens to be higher than any existing value in
+ * the index. No _bt_checkkeys are expected when _bt_readpage reads the
+ * rightmost page during such a scan -- even a _bt_checkkeys call against
+ * the high key won't happen. There is an analogous issue for backwards
+ * scans that search for a value lower than all existing index tuples.
+ *
+ * We don't actually require special handling for these cases -- we don't
+ * need to be explicitly instructed to _not_ perform another primitive
+ * index scan. This is correct for all of the cases we've listed so far,
+ * which all involve primitive index scans that access pages "near the
+ * boundaries of the key space" (the leftmost page, the rightmost page, or
+ * an imaginary empty leaf root page). If _bt_checkkeys cannot be reached
+ * by a primitive index scan for one set of array keys, it follows that it
+ * also won't be reached for any later set of array keys.
+ *
+ * There is one exception: the case where _bt_first's _bt_preprocess_keys
+ * call determined that the scan's input scan keys can never be satisfied.
+ * That might be true for one set of array keys, but not the next set.
+ */
+ if (!so->qual_ok)
+ {
+ /*
+ * Defensively check for interrupts -- the scan's next call to
+ * _bt_first won't be able to do so if the next set of keys also turn
+ * out to be unsatisfiable
+ */
+ CHECK_FOR_INTERRUPTS();
+
+ /* Can't use _bt_advance_array_keys so use incremental advancement */
+ so->needPrimScan = false;
+ if (_bt_advance_array_keys_increment(scan, dir))
+ return true;
+ }
+
+ /* Time for another primitive index scan? */
+ if (so->needPrimScan)
+ {
+ /* Have our caller call _bt_first once more */
+ so->needPrimScan = false;
+ if (scan->parallel_scan != NULL)
+ _bt_parallel_next_primitive_scan(scan);
+
+ return true;
+ }
+
+ if (scan->parallel_scan != NULL)
+ _bt_parallel_done(scan);
+
+ /*
+ * No more primitive index scans. Terminate the top-level scan.
+ */
+ return false;
+}
+
+/*
+ * _bt_advance_array_keys() -- Advance array elements using a tuple
+ *
+ * Returns true if all required equality-type scan keys (in particular, those
+ * that are array keys) now have exact matching values to those from tuple.
+ * Returns false when the tuple isn't an exact match in this sense.
+ *
+ * Sets pstate.continuescan for caller when we return false. When we return
+ * true it's up to caller to call _bt_check_compare to recheck the tuple. The
+ * second call should be allowed to set pstate.continuescan=false without
+ * further intervention, since tuple must be <= the array keys after we're
+ * called (actually, that guarantee applies to all required equality-type scan
+ * keys, and does not apply to non-required array keys).
+ *
+ * When called with skrequiredtrigger=true, the call only expects to have to
+ * deal with non-required equality array keys. The rules are a little
+ * different during these calls. We'll always set pstate.continuescan=true,
+ * since (by definition) a non-required scan key never terminates the scan.
+ *
+ * If we reach the end of all of the required array keys for the current scan
+ * direction, we will effectively end the top-level index scan.
+ *
+ * This function will always advance the array keys by at least one increment
+ * (except when it ends the top-level index scan having reached a tuple beyond
+ * the scan's final array key, and except during !skrequiredtrigger calls).
+ *
+ * _bt_tuple_before_array_skeys is responsible for determining if the current
+ * place in the scan is >= the current array keys. Calling here before that
+ * point will prematurely advance the array keys, leading to wrong query
+ * results (though this precondition is checked here via an assertion).
+ *
+ * We're responsible for ensuring that caller's tuple is <= current/newly
+ * advanced required array keys once we return (this postcondition is also
+ * checked via another assertion). We try to find an exact match, but failing
+ * that we'll advance the array keys to whatever set of keys comes next in the
+ * key space (among the keys that we actually have). In general, the scan's
+ * array keys can only ever "ratchet forwards", progressing in lock step with
+ * the scan.
+ *
+ * (The invariants are the same for backwards scans, except that the operators
+ * are flipped: just replace the precondition's >= operator with a <=, and the
+ * postcondition's <= operator with with a >=. In other words, just swap the
+ * precondition with the postcondition.)
+ *
+ * Note that we may sometimes need to advance the array keys in spite of the
+ * existing array keys already being an exact match for every corresponding
+ * value from caller's tuple. We fall back on "incrementally" advancing the
+ * array keys in these cases, which all involve non-array scan keys. For
+ * example, with a composite index on (a, b) and a qual "WHERE a IN (3,5) AND
+ * b < 42", we'll be called for both "a" keys (i.e. keys 3 and 5) when the
+ * scan reaches tuples where "b >= 42". Even though "a" array keys continue
+ * to have exact matches for tuples "b >= 42" (for both array key groupings),
+ * we will still advance the array for "a" via our fallback on incremental
+ * advancement each time we're called. The first time we're called (when the
+ * scan reaches a tuple >= "(3, 42)"), we advance the array key (from 3 to 5).
+ * This gives our caller the option of starting a new primitive index scan
+ * that quickly locates the start of tuples > "(5, -inf)". The second time
+ * we're called (when the scan reaches a tuple >= "(5, 42)"), we incrementally
+ * advance the keys a second time. This second call ends the top-level scan.
+ *
+ * Note also that we deal with all required equality-type scan keys here; it's
+ * not limited to array scan keys. We need to handle non-array equality cases
+ * here because they're equality constraints for the scan, in the same way
+ * that array scan keys are.
+ */
+static bool
+_bt_advance_array_keys(IndexScanDesc scan, BTReadPageState *pstate,
+ IndexTuple tuple, bool skrequiredtrigger)
+{
+ BTScanOpaque so = (BTScanOpaque) scan->opaque;
+ Relation rel = scan->indexRelation;
+ ScanDirection dir = pstate->dir;
+ TupleDesc itupdesc = RelationGetDescr(rel);
+ ScanKey cur;
+ int ikey,
+ arrayidx = 0,
+ ntupatts = BTreeTupleGetNAtts(tuple, rel);
+ bool arrays_advanced = false,
+ arrays_exhausted,
+ beyond_end_advance = false,
+ all_eqtype_sk_equal = true,
+ all_required_eqtype_sk_equal PG_USED_FOR_ASSERTS_ONLY = true;
+
+ /*
+ * Must only be called when tuple is >= current required array keys
+ * (except during backwards scans, when it must be <= the array keys)
+ */
+ Assert(_bt_verify_array_scankeys(scan));
+ Assert(!skrequiredtrigger ||
+ !_bt_tuple_before_array_skeys(scan, pstate, tuple));
+
+ /*
+ * Try to advance array keys via a series of binary searches.
+ *
+ * Loop iterates through the current scankeys (so->keyData, which were
+ * output by _bt_preprocess_keys earlier) and then sets input scan keys
+ * (so->arrayKeyData scan keys) to new array values.
+ */
+ for (cur = so->keyData, ikey = 0; ikey < so->numberOfKeys; cur++, ikey++)
+ {
+ BTArrayKeyInfo *array = NULL;
+ ScanKey skeyarray = NULL;
+ FmgrInfo *orderproc;
+ int attnum = cur->sk_attno,
+ set_elem = 0;
+ Datum tupdatum;
+ bool skrequired,
+ tupnull;
+ int32 result;
+
+ /*
+ * We only deal with equality strategy scan keys. We leave handling
+ * of inequalities up to _bt_check_compare.
+ */
+ if (cur->sk_strategy != BTEqualStrategyNumber)
+ continue;
+
+ /*
+ * Determine if this scan key is required.
+ *
+ * Equality strategy scan keys are either required in both directions
+ * or neither direction, so the current scan direction doesn't need to
+ * be tested here.
+ */
+ skrequired = (cur->sk_flags & SK_BT_REQFWD);
+ Assert(!skrequired || (cur->sk_flags & SK_BT_REQBKWD));
+
+ /*
+ * Set up ORDER 3-way comparison function and array state
+ */
+ orderproc = &so->orderProcs[attnum - 1];
+ if (cur->sk_flags & SK_SEARCHARRAY)
+ {
+ Assert(arrayidx < so->numArrayKeys);
+ array = &so->arrayKeys[arrayidx++];
+ skeyarray = &so->arrayKeyData[array->scan_key];
+ Assert(skeyarray->sk_attno == attnum);
+ }
+
+ /*
+ * Optimization: Skip over non-required scan keys when we know that
+ * they can't have changed (because _bt_check_compare triggered this
+ * call due to encountering an unsatisified non-required array qual)
+ */
+ if (skrequired && !skrequiredtrigger)
+ {
+ Assert(!beyond_end_advance && !arrays_advanced);
+
+ continue;
+ }
+
+ /*
+ * Here we perform steps for all array scan keys after a required
+ * array scan key whose binary search triggered "beyond end of array
+ * element" array advancement due to encountering a tuple attribute
+ * value > the closest matching array key (or < for backwards scans).
+ *
+ * We help to make sure that the array keys are ultimately advanced
+ * such that caller's tuple is < final array keys (or > final keys).
+ * We're behind the scan right now, but we'll fully "catch up" once
+ * outside the loop (we'll be immediately ahead of this tuple). See
+ * below for a detailed explanation.
+ *
+ * NB: We must do this for all arrays -- not just required arrays.
+ * Otherwise the final incremental array advancement step (that takes
+ * place just outside the loop) won't "carry" in the way we expect.
+ */
+ if (beyond_end_advance)
+ {
+ int final_elem_dir;
+
+ Assert(skrequiredtrigger);
+ Assert(!all_eqtype_sk_equal && !all_required_eqtype_sk_equal);
+
+ if (ScanDirectionIsBackward(dir) || !array)
+ final_elem_dir = 0;
+ else
+ final_elem_dir = array->num_elems - 1;
+
+ if (array && array->cur_elem != final_elem_dir)
+ {
+ array->cur_elem = final_elem_dir;
+ skeyarray->sk_argument = array->elem_values[final_elem_dir];
+ arrays_advanced = true;
+ }
+
+ continue;
+ }
+
+ /*
+ * Here we perform steps for any required scan keys after the first
+ * required scan key whose tuple attribute was < the closest matching
+ * array key when we dealt with it (or > for backwards scans).
+ *
+ * This earlier required array key already puts us ahead of caller's
+ * tuple in the key space (for the current scan direction). We must
+ * make sure that subsequent lower-order array keys do not put us too
+ * far ahead (ahead of tuples that have yet to be seen by our caller).
+ * For example, when a tuple "(a, b) = (42, 5)" advances the array
+ * keys on "a" from 40 to 45, we must also set "b" to whatever the
+ * first array element for "b" is. It would be wrong to allow "b" to
+ * be set to a value from the tuple, since the value is actually from
+ * a different part of the key space.
+ *
+ * Also perform the same steps with truncated high key attributes.
+ * You can think of this as a "binary search" for the element closest
+ * to the value -inf. This is another case where we have to avoid
+ * getting too far ahead of the scan.
+ */
+ if (!all_eqtype_sk_equal || attnum > ntupatts)
+ {
+ int first_elem_dir;
+
+ Assert((skrequiredtrigger && arrays_advanced) ||
+ attnum > ntupatts);
+ Assert(!beyond_end_advance);
+
+ if (ScanDirectionIsForward(dir) || !array)
+ first_elem_dir = 0;
+ else
+ first_elem_dir = array->num_elems - 1;
+
+ if (array && array->cur_elem != first_elem_dir)
+ {
+ array->cur_elem = first_elem_dir;
+ skeyarray->sk_argument = array->elem_values[first_elem_dir];
+ arrays_advanced = true;
+ }
+
+ continue;
+ }
+
+ /*
+ * Search in scankey's array for the corresponding tuple attribute
+ * value from caller's tuple
+ */
+ tupdatum = index_getattr(tuple, attnum, itupdesc, &tupnull);
+
+ if (!array)
+ {
+ if (!skrequired)
+ continue;
+
+ /*
+ * This is a required non-array equality strategy scan key, which
+ * we'll treat as a degenerate single value array
+ */
+ result = _bt_compare_array_skey(orderproc, tupdatum, tupnull,
+ cur->sk_argument, cur);
+ }
+ else
+ {
+ /* Determine if search bounds are reusable (optimization) */
+ bool cur_elem_start = (skrequired && !arrays_advanced);
+
+ /*
+ * Binary search for closest match that's available from the array
+ */
+ set_elem = _bt_binsrch_array_skey(orderproc, cur_elem_start, dir,
+ tupdatum, tupnull, array, cur,
+ &result);
+ }
+
+ /* Consider advancing array keys */
+ Assert(!array || (set_elem >= 0 && set_elem < array->num_elems));
+ if (array && array->cur_elem != set_elem)
+ {
+ array->cur_elem = set_elem;
+ skeyarray->sk_argument = array->elem_values[set_elem];
+ arrays_advanced = true;
+
+ /*
+ * We shouldn't have to advance a required array when called due
+ * to _bt_check_compare determining that a non-required array
+ * needs to be advanced. We expect _bt_check_compare to notice
+ * and report required scan keys before non-required ones.
+ */
+ Assert(skrequiredtrigger || !skrequired);
+ }
+
+ /*
+ * Consider "beyond end of array element" array advancement.
+ *
+ * When the tuple attribute value is > the closest matching array key
+ * (or < in the backwards scan case), we need to ratchet the array
+ * forward (backward) by one position, so that the array is set to a
+ * value < the tuple attribute value instead (or to a value > tuple's
+ * value).
+ *
+ * This process has to work for all of the arrays, not just this one:
+ * it must "carry" to higher-order arrays when the set_elem that we
+ * just used for this array happens to have been the final element
+ * (final for the current scan direction). That's why we don't handle
+ * this issue by modifying this array's set_elem (that won't "carry").
+ *
+ * Our approach is to set each subsequent lower-order array to its
+ * final element. We'll then advance the array keys incrementally,
+ * just outside the loop. That way earlier/higher order arrays
+ * (arrays before _this_ array) can advance as and when required.
+ *
+ * The array keys advance a little like the way that an mileage gauge
+ * advances. Imagine a mechanical display that rolls over from 999 to
+ * 000 every time we drive our car another 1,000 miles. Each decimal
+ * digit behaves a little like an array from the array state machine
+ * implemented by this function.
+ *
+ * Suppose we have 3 array keys a, b, and c. Each "digit"/array has
+ * 10 distinct elements that happen to match across each array: values
+ * 0 through to 9. Caller's tuple "(a, b, c) = (3, 7.9, 2)" might
+ * initially have its "b" array advanced up to the value 7 (7 being
+ * the closest match the "b" array has), and its "c" array advanced up
+ * to 9. The incremental advancement step (outside the loop) will
+ * then finish the process by "advancing" (actually, rolling over) the
+ * array on "c" to the value 0, which would immediately carry over to
+ * "b", which will then advance to the value 8 ("rounding up" from 7).
+ * Under this scheme, the array keys only ever ratchet forward, and
+ * array key advancement by us takes place as infrequently as possible
+ * (see also: this function's postcondition assertions, below).
+ *
+ * Incremental advancement can also carry all the way past the most
+ * significant array, exhausting all of the scan's array keys in one
+ * step. Suppose, for example, that a later call here passes a tuple
+ * "(a, b, c) = (9, 9.9, 4)". Once again we can't find an exact match
+ * for "b", so we'll set beyond_end_advance. This time, incremental
+ * advancement rolls over all the way past "a", the most significant
+ * array. _bt_advance_array_keys_increment will return false when
+ * this happens, indicating that all array keys are now exhausted.
+ * This triggers the end of the top-level index scan below.
+ */
+ Assert(!beyond_end_advance);
+ if (skrequired &&
+ ((ScanDirectionIsForward(dir) && result > 0) ||
+ (ScanDirectionIsBackward(dir) && result < 0)))
+ beyond_end_advance = true;
+
+ /*
+ * Also track whether all attributes from the tuple are equal to the
+ * array keys that we'll be advancing to (or to existing array keys
+ * that didn't need to be advanced)
+ */
+ if (result != 0)
+ {
+ all_eqtype_sk_equal = false;
+ if (skrequired)
+ all_required_eqtype_sk_equal = false;
+
+ /* Just skip if triggered by a non-required scan key */
+ if (!skrequiredtrigger)
+ break;
+ }
+ }
+
+ /*
+ * Consider if we need to advance the array keys incrementally to finish
+ * off "beyond end of array element" array advancement.
+ *
+ * Also fall back on incremental advancement in cases where we couldn't
+ * advance the array keys any other way. See function header comments for
+ * an example of this, where inequality-type scan keys alone drive array
+ * key advancement. (We don't directly deal with inequality type scan
+ * keys here, but cases that use the fallback must involve inequalities.)
+ */
+ arrays_exhausted = false;
+ if ((beyond_end_advance || !arrays_advanced) && skrequiredtrigger)
+ {
+ /* Fallback case must have all-equal equality type scan keys */
+ Assert(beyond_end_advance || all_required_eqtype_sk_equal);
+
+ if (!_bt_advance_array_keys_increment(scan, dir))
+ arrays_exhausted = true;
+ else
+ arrays_advanced = true;
+
+ /*
+ * The newly advanced array keys won't be equal anymore, so remember
+ * that in order to avoid a second _bt_check_compare call for tuple
+ */
+ all_eqtype_sk_equal = all_required_eqtype_sk_equal = false;
+ }
+
+ Assert(arrays_exhausted || arrays_advanced || !skrequiredtrigger);
+
+ /*
+ * If we haven't yet exhausted all required array scan keys, allow the
+ * ongoing primitive index scan to continue
+ */
+ pstate->continuescan = !arrays_exhausted;
+
+ /* Cannot set continuescan=false when called for non-required array */
+ Assert(pstate->continuescan || skrequiredtrigger);
+
+ if (arrays_advanced)
+ {
+ /*
+ * We advanced the array keys, and so must perform a targeted form of
+ * in-place preprocessing of the scan's search-type scan keys.
+ *
+ * If we missed this final step then any call to _bt_check_compare
+ * would use stale array keys until such time as _bt_preprocess_keys
+ * was once again called by _bt_first. But it's a good idea to do
+ * this even when there won't be another primitive index scan.
+ */
+ _bt_preprocess_keys_leafbuf(scan);
+
+ /*
+ * If any required array keys were advanced, be prepared to recheck
+ * the final tuple against the new array keys (as an optimization)
+ */
+ if (skrequiredtrigger)
+ pstate->finaltupchecked = false;
+ }
+
+ /*
+ * Postcondition assertions.
+ *
+ * Tuple must now be <= current/newly advanced required array keys. Same
+ * goes for other required equality type scan keys, which are "degenerate
+ * single value arrays" for our purposes. (As usual the rule is the same
+ * for backwards scans, but the operator is flipped: tuple must be >= new
+ * array keys.)
+ *
+ * We're stricter than that in cases where the tuple was already equal to
+ * the previous array keys when we were called: tuple must now be < the
+ * new array keys (or > the array keys). This is a consequence of the
+ * fallback on incremental advancement used to indirectly handle cases
+ * where an inequality triggers array key advancement. (See function
+ * header comments for an example of this.)
+ *
+ * Our caller decides when to start primitive index scans based in part on
+ * the current array keys. It always needs to see a precise array-wise
+ * picture of the scan's progress. If we ever advanced the array keys by
+ * less than the exact maximum safe amount, our caller might go on to make
+ * subtly wrong decisions about when to quit the ongoing primitive scan.
+ * (These assertions won't reliably detect every case where the array keys
+ * haven't advance by the expected/maximum amount, but they come close.)
+ */
+ Assert(_bt_verify_array_scankeys(scan));
+ Assert(_bt_tuple_before_array_skeys(scan, pstate, tuple) ==
+ (!all_required_eqtype_sk_equal && !arrays_exhausted));
+
+ /* All-equal required equality keys shouldn't be from before this call */
+ Assert(!all_required_eqtype_sk_equal || !skrequiredtrigger ||
+ arrays_advanced || arrays_exhausted);
+
+ return all_eqtype_sk_equal && pstate->continuescan;
+}
/*
* _bt_preprocess_keys() -- Preprocess scan keys
@@ -749,6 +1767,21 @@ _bt_restore_array_keys(IndexScanDesc scan)
* Again, missing cross-type operators might cause us to fail to prove the
* quals contradictory when they really are, but the scan will work correctly.
*
+ * Index scans with array keys need to be able to advance each array's keys
+ * and make them the current search-type scan keys without calling here. They
+ * expect to be able to call _bt_preprocess_keys_leafbuf instead (a stripped
+ * down version of this function that's specialized to array key index scans).
+ * We need to be careful about that case here when we determine redundancy;
+ * equality quals must not be eliminated as redundant on the basis of array
+ * input keys that might change before another call here takes place.
+ *
+ * Note, however, that the presence of an array scan key doesn't affect how we
+ * determine if index quals are contradictory. Contradictory qual scans move
+ * on to the next primitive index scan right away, by incrementing the scan's
+ * array keys once control reaches _bt_array_keys_remain. There won't ever be
+ * a call to _bt_preprocess_keys_leafbuf before the next call here, so there
+ * is nothing for us to break.
+ *
* Row comparison keys are currently also treated without any smarts:
* we just transfer them into the preprocessed array without any
* editorialization. We can treat them the same as an ordinary inequality
@@ -895,8 +1928,11 @@ _bt_preprocess_keys(IndexScanDesc scan)
so->qual_ok = false;
return;
}
- /* else discard the redundant non-equality key */
- xform[j] = NULL;
+ else if (!(eq->sk_flags & SK_SEARCHARRAY))
+ {
+ /* else discard the redundant non-equality key */
+ xform[j] = NULL;
+ }
}
/* else, cannot determine redundancy, keep both keys */
}
@@ -986,6 +2022,22 @@ _bt_preprocess_keys(IndexScanDesc scan)
continue;
}
+ /*
+ * Is this an array scan key that _bt_preprocess_array_keys merged
+ * with some earlier array key during its initial preprocessing pass?
+ */
+ if (cur->sk_flags & SK_BT_RDDNARRAY)
+ {
+ /*
+ * key is redundant for this primitive index scan (and will be
+ * redundant during all subsequent primitive index scans)
+ */
+ Assert(cur->sk_flags & SK_SEARCHARRAY);
+ Assert(j == (BTEqualStrategyNumber - 1));
+ Assert(so->numArrayKeys > 0);
+ continue;
+ }
+
/* have we seen one of these before? */
if (xform[j] == NULL)
{
@@ -999,7 +2051,26 @@ _bt_preprocess_keys(IndexScanDesc scan)
&test_result))
{
if (test_result)
- xform[j] = cur;
+ {
+ if (j == (BTEqualStrategyNumber - 1) &&
+ ((xform[j]->sk_flags & SK_SEARCHARRAY) ||
+ (cur->sk_flags & SK_SEARCHARRAY)))
+ {
+ /*
+ * Must never replace an = array operator ourselves,
+ * nor can we ever fail to remember an = array
+ * operator. _bt_preprocess_keys_leafbuf expects
+ * this.
+ */
+ ScanKey outkey = &outkeys[new_numberOfKeys++];
+
+ memcpy(outkey, cur, sizeof(ScanKeyData));
+ if (numberOfEqualCols == attno - 1)
+ _bt_mark_scankey_required(outkey);
+ }
+ else
+ xform[j] = cur;
+ }
else if (j == (BTEqualStrategyNumber - 1))
{
/* key == a && key == b, but a != b */
@@ -1027,6 +2098,96 @@ _bt_preprocess_keys(IndexScanDesc scan)
so->numberOfKeys = new_numberOfKeys;
}
+/*
+ * _bt_preprocess_keys_leafbuf() -- Preprocess array scan keys only
+ *
+ * Stripped down version of _bt_preprocess_keys that can be called with a
+ * buffer lock held. Reuses much of the work performed during the previous
+ * _bt_preprocess_keys call.
+ *
+ * This function just transfers newly advanced array keys that were set in
+ * "so->arrayKeyData" to corresponding "so->keyData" search-type scan keys.
+ * It does not independently detect redunant or contradictory scan keys.
+ */
+static void
+_bt_preprocess_keys_leafbuf(IndexScanDesc scan)
+{
+ BTScanOpaque so = (BTScanOpaque) scan->opaque;
+ ScanKey cur;
+ int ikey,
+ arrayidx = 0;
+
+ Assert(so->qual_ok);
+
+ for (cur = so->keyData, ikey = 0; ikey < so->numberOfKeys; cur++, ikey++)
+ {
+ BTArrayKeyInfo *array;
+ ScanKey skeyarray;
+
+ Assert((cur->sk_flags & SK_BT_RDDNARRAY) == 0);
+
+ /* Just update equality array scan keys */
+ if (cur->sk_strategy != BTEqualStrategyNumber ||
+ !(cur->sk_flags & SK_SEARCHARRAY))
+ continue;
+
+ array = &so->arrayKeys[arrayidx++];
+ skeyarray = &so->arrayKeyData[array->scan_key];
+
+ /* Update the scan key's argument */
+ Assert(cur->sk_attno == skeyarray->sk_attno);
+ cur->sk_argument = skeyarray->sk_argument;
+ }
+
+ Assert(arrayidx == so->numArrayKeys);
+}
+
+/*
+ * Verify that the scan's "so->arrayKeyData" scan keys are in agreement with
+ * the current "so->keyData" search-type scan keys. Used within assertions.
+ */
+#ifdef USE_ASSERT_CHECKING
+static bool
+_bt_verify_array_scankeys(IndexScanDesc scan)
+{
+ BTScanOpaque so = (BTScanOpaque) scan->opaque;
+ ScanKey cur;
+ int ikey,
+ arrayidx = 0;
+
+ if (!so->qual_ok)
+ return false;
+
+ for (cur = so->keyData, ikey = 0; ikey < so->numberOfKeys; cur++, ikey++)
+ {
+ BTArrayKeyInfo *array;
+ ScanKey skeyarray;
+
+ if (cur->sk_strategy != BTEqualStrategyNumber ||
+ !(cur->sk_flags & SK_SEARCHARRAY))
+ continue;
+
+ array = &so->arrayKeys[arrayidx++];
+ skeyarray = &so->arrayKeyData[array->scan_key];
+
+ /* Verify so->arrayKeyData input scan key has expected sk_argument */
+ if (skeyarray->sk_argument != array->elem_values[array->cur_elem])
+ return false;
+
+ /* Verify so->arrayKeyData input scan key agrees with output key */
+ if (cur->sk_attno != skeyarray->sk_attno)
+ return false;
+ if (cur->sk_argument != skeyarray->sk_argument)
+ return false;
+ }
+
+ if (arrayidx != so->numArrayKeys)
+ return false;
+
+ return true;
+}
+#endif
+
/*
* Compare two scankey values using a specified operator.
*
@@ -1360,41 +2521,198 @@ _bt_mark_scankey_required(ScanKey skey)
*
* Return true if so, false if not. If the tuple fails to pass the qual,
* we also determine whether there's any need to continue the scan beyond
- * this tuple, and set *continuescan accordingly. See comments for
+ * this tuple, and set pstate.continuescan accordingly. See comments for
* _bt_preprocess_keys(), above, about how this is done.
*
- * Forward scan callers can pass a high key tuple in the hopes of having
- * us set *continuescan to false, and avoiding an unnecessary visit to
- * the page to the right.
+ * Forward scan callers can pass a high key tuple in the hopes of having us
+ * set pstate.continuescan to false, and avoiding an unnecessary visit to the
+ * page to the right.
+ *
+ * Forwards scan callers with equality type array scan keys are obligated to
+ * set up page state in a way that makes it possible for us to check the final
+ * tuple (the high key for a forward scan) early, before we've expended too
+ * much effort on comparing tuples that cannot possibly be matches for any set
+ * of array keys. This is just an optimization.
+ *
+ * Advances the current set of array keys for SK_SEARCHARRAY scans where
+ * appropriate. These callers are required to initialize the page level high
+ * key in pstate before the first call here for the page (when the scan
+ * direction is forwards). Note that we rely on _bt_readpage calling here in
+ * page offset number order (for its scan direction). Any other order will
+ * lead to inconsistent array key state.
*
* scan: index scan descriptor (containing a search-type scankey)
+ * pstate: Page level input and output parameters
* tuple: index tuple to test
- * tupnatts: number of attributes in tupnatts (high key may be truncated)
- * dir: direction we are scanning in
- * continuescan: output parameter (will be set correctly in all cases)
+ * finaltup: Is tuple the final one we'll be called with for this page?
* requiredMatchedByPrecheck: indicates that scan keys required for
* direction scan are already matched
*/
bool
-_bt_checkkeys(IndexScanDesc scan, IndexTuple tuple, int tupnatts,
- ScanDirection dir, bool *continuescan,
+_bt_checkkeys(IndexScanDesc scan, BTReadPageState *pstate,
+ IndexTuple tuple, bool finaltup,
bool requiredMatchedByPrecheck)
{
- TupleDesc tupdesc;
- BTScanOpaque so;
- int keysz;
+ TupleDesc tupdesc = RelationGetDescr(scan->indexRelation);
+ int natts = BTreeTupleGetNAtts(tuple, scan->indexRelation);
+ BTScanOpaque so = (BTScanOpaque) scan->opaque;
+ bool res;
+ bool skrequiredtrigger;
+
+ Assert(pstate->continuescan);
+ Assert(!so->needPrimScan);
+
+ res = _bt_check_compare(pstate->dir, so, tuple, natts, tupdesc,
+ &pstate->continuescan, &skrequiredtrigger,
+ requiredMatchedByPrecheck);
+
+ /*
+ * Only one _bt_check_compare call is required in the common case where
+ * there are no equality-type array scan keys.
+ *
+ * When there are array scan keys then we can still accept the first
+ * answer we get from _bt_check_compare when continuescan wasn't unset.
+ */
+ if (!so->numArrayKeys || pstate->continuescan)
+ return res;
+
+ /*
+ * _bt_check_compare set continuescan=false in the presence of equality
+ * type array keys. It's possible that we haven't reached the start of
+ * the array keys just yet. It's also possible that we need to advance
+ * the array keys now. (Or perhaps we really do need to terminate the
+ * top-level scan.)
+ */
+ pstate->continuescan = true; /* new initial assumption */
+
+ if (skrequiredtrigger && _bt_tuple_before_array_skeys(scan, pstate, tuple))
+ {
+ /*
+ * Tuple is still < the current array scan key values (as well as
+ * other equality type scan keys) if this is a forward scan.
+ * (Backwards scans reach here with a tuple > equality constraints.)
+ * We must now consider how to proceed with the ongoing primitive
+ * index scan.
+ *
+ * Should _bt_readpage continue with this page for now, in the hope of
+ * finding tuples whose key space is covered by the current array keys
+ * before too long? Or, should it give up and start a new primitive
+ * index scan instead?
+ *
+ * Our policy is to terminate the primitive index scan at the end of
+ * the current page if the current (most recently advanced) array keys
+ * don't cover the final tuple from the page. This policy is fairly
+ * conservative overall. Note, however, that our policy effectively
+ * infers what the next sibling page is likely to look like based on
+ * details from the current page (in particular its final tuple).
+ *
+ * It's possible that we'll gamble and lose: a grouping of tuples
+ * covered by the current array keys could be aligned with the key
+ * space boundaries of the current leaf page, without any later array
+ * keys having key space that is covered by the next sibling page.
+ */
+ if (finaltup || (!pstate->finaltupchecked && pstate->finaltup &&
+ _bt_tuple_before_array_skeys(scan, pstate,
+ pstate->finaltup)))
+ {
+ /*
+ * This is the final tuple (the high key for forward scans, or the
+ * tuple at the first offset number for backward scans), but it is
+ * still before the current array keys. As such, we're unwilling
+ * to allow the current primitive index scan to continue to the
+ * next leaf page. Start a new primitive index scan that will
+ * reposition the top-level scan to the first leaf page whose key
+ * space is covered by our _current_ array keys. We expect that
+ * this process will effectively make the scan "skip over" a group
+ * of leaf pages that cannot possibly contain any matching tuples.
+ *
+ * Note: _bt_readpage stashes the final tuple, which allows us to
+ * make this check early. We thereby avoid comparing very many
+ * extra tuples on the page. This is just an optimization;
+ * skipping these useless comparisons should never change our
+ * final conclusion about what the scan should do next.
+ */
+ pstate->continuescan = false;
+ so->needPrimScan = true;
+ }
+ else if (!finaltup && pstate->finaltup)
+ {
+ /*
+ * Remember that the final tuple has been checked with this
+ * particular set of array keys.
+ *
+ * It might make sense to check the same tuple again at some point
+ * during the ongoing _bt_readpage-wise scan of this page. But it
+ * is definitely wasteful to repeat the same check before the
+ * array keys are advanced by some later non-final tuple.
+ */
+ pstate->finaltupchecked = true;
+ }
+
+ /*
+ * In any case, this indextuple doesn't match the qual
+ */
+ return false;
+ }
+
+ /*
+ * Caller's tuple is >= the current set of array keys and other equality
+ * constraint scan keys (or <= if this is a backwards scans).
+ *
+ * It it now time to advance the array keys based on the values from this
+ * tuple. Do that now, while determining in passing if the tuple matches
+ * the newly advanced set of array keys (if we've any left).
+ *
+ * This call will also set continuescan for us (or tells us to perform
+ * another _bt_check_compare call, which then sets continuescan for us).
+ */
+ if (!_bt_advance_array_keys(scan, pstate, tuple, skrequiredtrigger))
+ {
+ /*
+ * Tuple doesn't match any later array keys, either. Give up on this
+ * tuple being a match.
+ */
+ return false;
+ }
+
+ /*
+ * Advanced array keys to values that are exact matches for corresponding
+ * attribute values from the tuple. Check back with _bt_check_compare.
+ */
+ return _bt_check_compare(pstate->dir, so, tuple, natts, tupdesc,
+ &pstate->continuescan, &skrequiredtrigger,
+ false);
+}
+
+/*
+ * Test whether an indextuple satisfies current scan condition.
+ *
+ * Return true if so, false if not. If not, also clear *continuescan if
+ * it's not possible for any future tuples in the current scan direction to
+ * pass the qual with the current set of array keys.
+ *
+ * This is a subroutine for _bt_checkkeys. It is written with the assumption
+ * that reaching the end of each distinct set of array keys terminates the
+ * ongoing primitive index scan. It is up to our caller (that has more
+ * context than we have available here) to override that initial determination
+ * when it makes more sense to advance the array keys and continue with
+ * further tuples from the same leaf page.
+ */
+static bool
+_bt_check_compare(ScanDirection dir, BTScanOpaque so,
+ IndexTuple tuple, int tupnatts, TupleDesc tupdesc,
+ bool *continuescan, bool *skrequiredtrigger,
+ bool requiredMatchedByPrecheck)
+{
int ikey;
ScanKey key;
- Assert(BTreeTupleGetNAtts(tuple, scan->indexRelation) == tupnatts);
+ Assert(!so->numArrayKeys || !requiredMatchedByPrecheck);
*continuescan = true; /* default assumption */
+ *skrequiredtrigger = true; /* default assumption */
- tupdesc = RelationGetDescr(scan->indexRelation);
- so = (BTScanOpaque) scan->opaque;
- keysz = so->numberOfKeys;
-
- for (key = so->keyData, ikey = 0; ikey < keysz; key++, ikey++)
+ for (key = so->keyData, ikey = 0; ikey < so->numberOfKeys; key++, ikey++)
{
Datum datum;
bool isNull;
@@ -1526,7 +2844,7 @@ _bt_checkkeys(IndexScanDesc scan, IndexTuple tuple, int tupnatts,
* _bt_first() except for the NULLs checking, which have already done
* above.
*/
- if (!requiredOppositeDir)
+ if (!requiredOppositeDir || so->numArrayKeys)
{
test = FunctionCall2Coll(&key->sk_func, key->sk_collation,
datum, key->sk_argument);
@@ -1549,10 +2867,22 @@ _bt_checkkeys(IndexScanDesc scan, IndexTuple tuple, int tupnatts,
* qual fails, it is critical that equality quals be used for the
* initial positioning in _bt_first() when they are available. See
* comments in _bt_first().
+ *
+ * Scans with equality-type array scan keys run into a similar
+ * problem whenever they advance the array keys. Our caller uses
+ * _bt_tuple_before_array_skeys to avoid the problem there.
*/
if (requiredSameDir)
*continuescan = false;
+ if ((key->sk_flags & SK_SEARCHARRAY) &&
+ key->sk_strategy == BTEqualStrategyNumber)
+ {
+ if (!requiredSameDir)
+ *skrequiredtrigger = false;
+ *continuescan = false;
+ }
+
/*
* In any case, this indextuple doesn't match the qual.
*/
@@ -1571,7 +2901,7 @@ _bt_checkkeys(IndexScanDesc scan, IndexTuple tuple, int tupnatts,
* it's not possible for any future tuples in the current scan direction
* to pass the qual.
*
- * This is a subroutine for _bt_checkkeys, which see for more info.
+ * This is a subroutine for _bt_checkkeys/_bt_check_compare.
*/
static bool
_bt_check_rowcompare(ScanKey skey, IndexTuple tuple, int tupnatts,
diff --git a/src/backend/optimizer/path/indxpath.c b/src/backend/optimizer/path/indxpath.c
index 03a5fbdc6..e37597c26 100644
--- a/src/backend/optimizer/path/indxpath.c
+++ b/src/backend/optimizer/path/indxpath.c
@@ -106,8 +106,7 @@ static List *build_index_paths(PlannerInfo *root, RelOptInfo *rel,
IndexOptInfo *index, IndexClauseSet *clauses,
bool useful_predicate,
ScanTypeControl scantype,
- bool *skip_nonnative_saop,
- bool *skip_lower_saop);
+ bool *skip_nonnative_saop);
static List *build_paths_for_OR(PlannerInfo *root, RelOptInfo *rel,
List *clauses, List *other_clauses);
static List *generate_bitmap_or_paths(PlannerInfo *root, RelOptInfo *rel,
@@ -706,8 +705,6 @@ eclass_already_used(EquivalenceClass *parent_ec, Relids oldrelids,
* index AM supports them natively, we should just include them in simple
* index paths. If not, we should exclude them while building simple index
* paths, and then make a separate attempt to include them in bitmap paths.
- * Furthermore, we should consider excluding lower-order ScalarArrayOpExpr
- * quals so as to create ordered paths.
*/
static void
get_index_paths(PlannerInfo *root, RelOptInfo *rel,
@@ -716,37 +713,17 @@ get_index_paths(PlannerInfo *root, RelOptInfo *rel,
{
List *indexpaths;
bool skip_nonnative_saop = false;
- bool skip_lower_saop = false;
ListCell *lc;
/*
* Build simple index paths using the clauses. Allow ScalarArrayOpExpr
- * clauses only if the index AM supports them natively, and skip any such
- * clauses for index columns after the first (so that we produce ordered
- * paths if possible).
+ * clauses only if the index AM supports them natively.
*/
indexpaths = build_index_paths(root, rel,
index, clauses,
index->predOK,
ST_ANYSCAN,
- &skip_nonnative_saop,
- &skip_lower_saop);
-
- /*
- * If we skipped any lower-order ScalarArrayOpExprs on an index with an AM
- * that supports them, then try again including those clauses. This will
- * produce paths with more selectivity but no ordering.
- */
- if (skip_lower_saop)
- {
- indexpaths = list_concat(indexpaths,
- build_index_paths(root, rel,
- index, clauses,
- index->predOK,
- ST_ANYSCAN,
- &skip_nonnative_saop,
- NULL));
- }
+ &skip_nonnative_saop);
/*
* Submit all the ones that can form plain IndexScan plans to add_path. (A
@@ -784,7 +761,6 @@ get_index_paths(PlannerInfo *root, RelOptInfo *rel,
index, clauses,
false,
ST_BITMAPSCAN,
- NULL,
NULL);
*bitindexpaths = list_concat(*bitindexpaths, indexpaths);
}
@@ -817,27 +793,19 @@ get_index_paths(PlannerInfo *root, RelOptInfo *rel,
* to true if we found any such clauses (caller must initialize the variable
* to false). If it's NULL, we do not ignore ScalarArrayOpExpr clauses.
*
- * If skip_lower_saop is non-NULL, we ignore ScalarArrayOpExpr clauses for
- * non-first index columns, and we set *skip_lower_saop to true if we found
- * any such clauses (caller must initialize the variable to false). If it's
- * NULL, we do not ignore non-first ScalarArrayOpExpr clauses, but they will
- * result in considering the scan's output to be unordered.
- *
* 'rel' is the index's heap relation
* 'index' is the index for which we want to generate paths
* 'clauses' is the collection of indexable clauses (IndexClause nodes)
* 'useful_predicate' indicates whether the index has a useful predicate
* 'scantype' indicates whether we need plain or bitmap scan support
* 'skip_nonnative_saop' indicates whether to accept SAOP if index AM doesn't
- * 'skip_lower_saop' indicates whether to accept non-first-column SAOP
*/
static List *
build_index_paths(PlannerInfo *root, RelOptInfo *rel,
IndexOptInfo *index, IndexClauseSet *clauses,
bool useful_predicate,
ScanTypeControl scantype,
- bool *skip_nonnative_saop,
- bool *skip_lower_saop)
+ bool *skip_nonnative_saop)
{
List *result = NIL;
IndexPath *ipath;
@@ -848,7 +816,6 @@ build_index_paths(PlannerInfo *root, RelOptInfo *rel,
List *orderbyclausecols;
List *index_pathkeys;
List *useful_pathkeys;
- bool found_lower_saop_clause;
bool pathkeys_possibly_useful;
bool index_is_ordered;
bool index_only_scan;
@@ -880,19 +847,11 @@ build_index_paths(PlannerInfo *root, RelOptInfo *rel,
* on by btree and possibly other places.) The list can be empty, if the
* index AM allows that.
*
- * found_lower_saop_clause is set true if we accept a ScalarArrayOpExpr
- * index clause for a non-first index column. This prevents us from
- * assuming that the scan result is ordered. (Actually, the result is
- * still ordered if there are equality constraints for all earlier
- * columns, but it seems too expensive and non-modular for this code to be
- * aware of that refinement.)
- *
* We also build a Relids set showing which outer rels are required by the
* selected clauses. Any lateral_relids are included in that, but not
* otherwise accounted for.
*/
index_clauses = NIL;
- found_lower_saop_clause = false;
outer_relids = bms_copy(rel->lateral_relids);
for (indexcol = 0; indexcol < index->nkeycolumns; indexcol++)
{
@@ -903,30 +862,20 @@ build_index_paths(PlannerInfo *root, RelOptInfo *rel,
IndexClause *iclause = (IndexClause *) lfirst(lc);
RestrictInfo *rinfo = iclause->rinfo;
- /* We might need to omit ScalarArrayOpExpr clauses */
- if (IsA(rinfo->clause, ScalarArrayOpExpr))
+ /*
+ * We might need to omit ScalarArrayOpExpr clauses when index AM
+ * lacks native support
+ */
+ if (!index->amsearcharray && IsA(rinfo->clause, ScalarArrayOpExpr))
{
- if (!index->amsearcharray)
+ if (skip_nonnative_saop)
{
- if (skip_nonnative_saop)
- {
- /* Ignore because not supported by index */
- *skip_nonnative_saop = true;
- continue;
- }
- /* Caller had better intend this only for bitmap scan */
- Assert(scantype == ST_BITMAPSCAN);
- }
- if (indexcol > 0)
- {
- if (skip_lower_saop)
- {
- /* Caller doesn't want to lose index ordering */
- *skip_lower_saop = true;
- continue;
- }
- found_lower_saop_clause = true;
+ /* Ignore because not supported by index */
+ *skip_nonnative_saop = true;
+ continue;
}
+ /* Caller had better intend this only for bitmap scan */
+ Assert(scantype == ST_BITMAPSCAN);
}
/* OK to include this clause */
@@ -956,11 +905,9 @@ build_index_paths(PlannerInfo *root, RelOptInfo *rel,
/*
* 2. Compute pathkeys describing index's ordering, if any, then see how
* many of them are actually useful for this query. This is not relevant
- * if we are only trying to build bitmap indexscans, nor if we have to
- * assume the scan is unordered.
+ * if we are only trying to build bitmap indexscans.
*/
pathkeys_possibly_useful = (scantype != ST_BITMAPSCAN &&
- !found_lower_saop_clause &&
has_useful_pathkeys(root, rel));
index_is_ordered = (index->sortopfamily != NULL);
if (index_is_ordered && pathkeys_possibly_useful)
@@ -1212,7 +1159,6 @@ build_paths_for_OR(PlannerInfo *root, RelOptInfo *rel,
index, &clauseset,
useful_predicate,
ST_BITMAPSCAN,
- NULL,
NULL);
result = list_concat(result, indexpaths);
}
diff --git a/src/backend/utils/adt/selfuncs.c b/src/backend/utils/adt/selfuncs.c
index c4fcd0076..1b899b2db 100644
--- a/src/backend/utils/adt/selfuncs.c
+++ b/src/backend/utils/adt/selfuncs.c
@@ -6444,8 +6444,6 @@ genericcostestimate(PlannerInfo *root,
double numIndexTuples;
double spc_random_page_cost;
double num_sa_scans;
- double num_outer_scans;
- double num_scans;
double qual_op_cost;
double qual_arg_cost;
List *selectivityQuals;
@@ -6460,7 +6458,7 @@ genericcostestimate(PlannerInfo *root,
/*
* Check for ScalarArrayOpExpr index quals, and estimate the number of
- * index scans that will be performed.
+ * primitive index scans that will be performed for caller
*/
num_sa_scans = 1;
foreach(l, indexQuals)
@@ -6490,19 +6488,8 @@ genericcostestimate(PlannerInfo *root,
*/
numIndexTuples = costs->numIndexTuples;
if (numIndexTuples <= 0.0)
- {
numIndexTuples = indexSelectivity * index->rel->tuples;
- /*
- * The above calculation counts all the tuples visited across all
- * scans induced by ScalarArrayOpExpr nodes. We want to consider the
- * average per-indexscan number, so adjust. This is a handy place to
- * round to integer, too. (If caller supplied tuple estimate, it's
- * responsible for handling these considerations.)
- */
- numIndexTuples = rint(numIndexTuples / num_sa_scans);
- }
-
/*
* We can bound the number of tuples by the index size in any case. Also,
* always estimate at least one tuple is touched, even when
@@ -6540,27 +6527,31 @@ genericcostestimate(PlannerInfo *root,
*
* The above calculations are all per-index-scan. However, if we are in a
* nestloop inner scan, we can expect the scan to be repeated (with
- * different search keys) for each row of the outer relation. Likewise,
- * ScalarArrayOpExpr quals result in multiple index scans. This creates
- * the potential for cache effects to reduce the number of disk page
- * fetches needed. We want to estimate the average per-scan I/O cost in
- * the presence of caching.
+ * different search keys) for each row of the outer relation. This
+ * creates the potential for cache effects to reduce the number of disk
+ * page fetches needed. We want to estimate the average per-scan I/O cost
+ * in the presence of caching.
*
* We use the Mackert-Lohman formula (see costsize.c for details) to
* estimate the total number of page fetches that occur. While this
* wasn't what it was designed for, it seems a reasonable model anyway.
* Note that we are counting pages not tuples anymore, so we take N = T =
* index size, as if there were one "tuple" per page.
+ *
+ * Note: we assume that there will be no repeat index page fetches across
+ * ScalarArrayOpExpr primitive scans from the same logical index scan.
+ * This is guaranteed to be true for btree indexes, but is very optimistic
+ * with index AMs that cannot natively execute ScalarArrayOpExpr quals.
+ * However, these same index AMs also accept our default pessimistic
+ * approach to counting num_sa_scans (btree caller caps this), so we don't
+ * expect the final indexTotalCost to be wildly over-optimistic.
*/
- num_outer_scans = loop_count;
- num_scans = num_sa_scans * num_outer_scans;
-
- if (num_scans > 1)
+ if (loop_count > 1)
{
double pages_fetched;
/* total page fetches ignoring cache effects */
- pages_fetched = numIndexPages * num_scans;
+ pages_fetched = numIndexPages * loop_count;
/* use Mackert and Lohman formula to adjust for cache effects */
pages_fetched = index_pages_fetched(pages_fetched,
@@ -6570,11 +6561,9 @@ genericcostestimate(PlannerInfo *root,
/*
* Now compute the total disk access cost, and then report a pro-rated
- * share for each outer scan. (Don't pro-rate for ScalarArrayOpExpr,
- * since that's internal to the indexscan.)
+ * share for each outer scan
*/
- indexTotalCost = (pages_fetched * spc_random_page_cost)
- / num_outer_scans;
+ indexTotalCost = (pages_fetched * spc_random_page_cost) / loop_count;
}
else
{
@@ -6590,10 +6579,8 @@ genericcostestimate(PlannerInfo *root,
* evaluated once at the start of the scan to reduce them to runtime keys
* to pass to the index AM (see nodeIndexscan.c). We model the per-tuple
* CPU costs as cpu_index_tuple_cost plus one cpu_operator_cost per
- * indexqual operator. Because we have numIndexTuples as a per-scan
- * number, we have to multiply by num_sa_scans to get the correct result
- * for ScalarArrayOpExpr cases. Similarly add in costs for any index
- * ORDER BY expressions.
+ * indexqual operator. Similarly add in costs for any index ORDER BY
+ * expressions.
*
* Note: this neglects the possible costs of rechecking lossy operators.
* Detecting that that might be needed seems more expensive than it's
@@ -6606,7 +6593,7 @@ genericcostestimate(PlannerInfo *root,
indexStartupCost = qual_arg_cost;
indexTotalCost += qual_arg_cost;
- indexTotalCost += numIndexTuples * num_sa_scans * (cpu_index_tuple_cost + qual_op_cost);
+ indexTotalCost += numIndexTuples * (cpu_index_tuple_cost + qual_op_cost);
/*
* Generic assumption about index correlation: there isn't any.
@@ -6684,7 +6671,6 @@ btcostestimate(PlannerInfo *root, IndexPath *path, double loop_count,
bool eqQualHere;
bool found_saop;
bool found_is_null_op;
- double num_sa_scans;
ListCell *lc;
/*
@@ -6699,17 +6685,12 @@ btcostestimate(PlannerInfo *root, IndexPath *path, double loop_count,
*
* For a RowCompareExpr, we consider only the first column, just as
* rowcomparesel() does.
- *
- * If there's a ScalarArrayOpExpr in the quals, we'll actually perform N
- * index scans not one, but the ScalarArrayOpExpr's operator can be
- * considered to act the same as it normally does.
*/
indexBoundQuals = NIL;
indexcol = 0;
eqQualHere = false;
found_saop = false;
found_is_null_op = false;
- num_sa_scans = 1;
foreach(lc, path->indexclauses)
{
IndexClause *iclause = lfirst_node(IndexClause, lc);
@@ -6749,14 +6730,9 @@ btcostestimate(PlannerInfo *root, IndexPath *path, double loop_count,
else if (IsA(clause, ScalarArrayOpExpr))
{
ScalarArrayOpExpr *saop = (ScalarArrayOpExpr *) clause;
- Node *other_operand = (Node *) lsecond(saop->args);
- int alength = estimate_array_length(other_operand);
clause_op = saop->opno;
found_saop = true;
- /* count number of SA scans induced by indexBoundQuals only */
- if (alength > 1)
- num_sa_scans *= alength;
}
else if (IsA(clause, NullTest))
{
@@ -6816,13 +6792,6 @@ btcostestimate(PlannerInfo *root, IndexPath *path, double loop_count,
JOIN_INNER,
NULL);
numIndexTuples = btreeSelectivity * index->rel->tuples;
-
- /*
- * As in genericcostestimate(), we have to adjust for any
- * ScalarArrayOpExpr quals included in indexBoundQuals, and then round
- * to integer.
- */
- numIndexTuples = rint(numIndexTuples / num_sa_scans);
}
/*
@@ -6832,6 +6801,48 @@ btcostestimate(PlannerInfo *root, IndexPath *path, double loop_count,
genericcostestimate(root, path, loop_count, &costs);
+ /*
+ * Now compensate for btree's ability to efficiently execute scans with
+ * SAOP clauses.
+ *
+ * btree automatically combines individual ScalarArrayOpExpr primitive
+ * index scans whenever the tuples covered by the next set of array keys
+ * are close to tuples covered by the current set. This makes the final
+ * number of descents particularly difficult to estimate. However, btree
+ * scans never visit any single leaf page more than once. That puts a
+ * natural floor under the worst case number of descents.
+ *
+ * It's particularly important that we not wildly overestimate the number
+ * of descents needed for a clause list with several SAOPs -- the costs
+ * really aren't multiplicative in the way genericcostestimate expects. In
+ * general, most distinct combinations of SAOP keys will tend to not find
+ * any matching tuples. Furthermore, btree scans search for the next set
+ * of array keys using the next tuple in line, and so won't even need a
+ * direct comparison to eliminate most non-matching sets of array keys.
+ *
+ * Clamp the number of descents to the estimated number of leaf page
+ * visits. This is still fairly pessimistic, but tends to result in more
+ * accurate costing of scans with several SAOP clauses -- especially when
+ * each array has more than a few elements. The cost of adding additional
+ * array constants to a low-order SAOP column should saturate past a
+ * certain point (except where selectivity estimates continue to shift).
+ *
+ * Also clamp the number of descents to 1/3 the number of index pages.
+ * This avoids implausibly high estimates with low selectivity paths,
+ * where scans frequently require no more than one or two descents.
+ *
+ * XXX Ideally, we'd also account for the fact that non-boundary SAOP
+ * clause quals (which the B-Tree code uses "non-required" scan keys for)
+ * won't actually contribute to the total number of descents of the index.
+ * This would require pushing down more context into genericcostestimate.
+ */
+ if (costs.num_sa_scans > 1)
+ {
+ costs.num_sa_scans = Min(costs.num_sa_scans, costs.numIndexPages);
+ costs.num_sa_scans = Min(costs.num_sa_scans, index->pages / 3);
+ costs.num_sa_scans = Max(costs.num_sa_scans, 1);
+ }
+
/*
* Add a CPU-cost component to represent the costs of initial btree
* descent. We don't charge any I/O cost for touching upper btree levels,
@@ -6839,9 +6850,9 @@ btcostestimate(PlannerInfo *root, IndexPath *path, double loop_count,
* comparisons to descend a btree of N leaf tuples. We charge one
* cpu_operator_cost per comparison.
*
- * If there are ScalarArrayOpExprs, charge this once per SA scan. The
- * ones after the first one are not startup cost so far as the overall
- * plan is concerned, so add them only to "total" cost.
+ * If there are ScalarArrayOpExprs, charge this once per estimated
+ * primitive SA scan. The ones after the first one are not startup cost
+ * so far as the overall plan goes, so just add them to "total" cost.
*/
if (index->tuples > 1) /* avoid computing log(0) */
{
@@ -6858,7 +6869,8 @@ btcostestimate(PlannerInfo *root, IndexPath *path, double loop_count,
* in cases where only a single leaf page is expected to be visited. This
* cost is somewhat arbitrarily set at 50x cpu_operator_cost per page
* touched. The number of such pages is btree tree height plus one (ie,
- * we charge for the leaf page too). As above, charge once per SA scan.
+ * we charge for the leaf page too). As above, charge once per estimated
+ * primitive SA scan.
*/
descentCost = (index->tree_height + 1) * DEFAULT_PAGE_CPU_MULTIPLIER * cpu_operator_cost;
costs.indexStartupCost += descentCost;
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index e068f7e24..da90412d5 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -4035,6 +4035,19 @@ description | Waiting for a newly initialized WAL file to reach durable storage
</para>
</note>
+ <note>
+ <para>
+ Every time an index is searched, the index's
+ <structname>pg_stat_all_indexes</structname>.<structfield>idx_scan</structfield>
+ field is incremented. This usually happens once per index scan node
+ execution, but might take place several times during execution of a scan
+ that searches for multiple values together. Only queries that use certain
+ <acronym>SQL</acronym> constructs to search for rows matching any value
+ out of a list (or an array) of multiple scalar values are affected. See
+ <xref linkend="functions-comparisons"/> for details.
+ </para>
+ </note>
+
</sect2>
<sect2 id="monitoring-pg-statio-all-tables-view">
diff --git a/src/test/regress/expected/create_index.out b/src/test/regress/expected/create_index.out
index acfd9d1f4..84c068ae3 100644
--- a/src/test/regress/expected/create_index.out
+++ b/src/test/regress/expected/create_index.out
@@ -1910,7 +1910,7 @@ SELECT count(*) FROM dupindexcols
(1 row)
--
--- Check ordering of =ANY indexqual results (bug in 9.2.0)
+-- Check that index scans with =ANY indexquals return rows in index order
--
explain (costs off)
SELECT unique1 FROM tenk1
@@ -1936,12 +1936,11 @@ explain (costs off)
SELECT thousand, tenthous FROM tenk1
WHERE thousand < 2 AND tenthous IN (1001,3000)
ORDER BY thousand;
- QUERY PLAN
--------------------------------------------------------
+ QUERY PLAN
+--------------------------------------------------------------------------------
Index Only Scan using tenk1_thous_tenthous on tenk1
- Index Cond: (thousand < 2)
- Filter: (tenthous = ANY ('{1001,3000}'::integer[]))
-(3 rows)
+ Index Cond: ((thousand < 2) AND (tenthous = ANY ('{1001,3000}'::integer[])))
+(2 rows)
SELECT thousand, tenthous FROM tenk1
WHERE thousand < 2 AND tenthous IN (1001,3000)
@@ -1952,18 +1951,35 @@ ORDER BY thousand;
1 | 1001
(2 rows)
+explain (costs off)
+SELECT thousand, tenthous FROM tenk1
+WHERE thousand < 2 AND tenthous IN (1001,3000)
+ORDER BY thousand DESC, tenthous DESC;
+ QUERY PLAN
+--------------------------------------------------------------------------------
+ Index Only Scan Backward using tenk1_thous_tenthous on tenk1
+ Index Cond: ((thousand < 2) AND (tenthous = ANY ('{1001,3000}'::integer[])))
+(2 rows)
+
+SELECT thousand, tenthous FROM tenk1
+WHERE thousand < 2 AND tenthous IN (1001,3000)
+ORDER BY thousand DESC, tenthous DESC;
+ thousand | tenthous
+----------+----------
+ 1 | 1001
+ 0 | 3000
+(2 rows)
+
SET enable_indexonlyscan = OFF;
explain (costs off)
SELECT thousand, tenthous FROM tenk1
WHERE thousand < 2 AND tenthous IN (1001,3000)
ORDER BY thousand;
- QUERY PLAN
---------------------------------------------------------------------------------------
- Sort
- Sort Key: thousand
- -> Index Scan using tenk1_thous_tenthous on tenk1
- Index Cond: ((thousand < 2) AND (tenthous = ANY ('{1001,3000}'::integer[])))
-(4 rows)
+ QUERY PLAN
+--------------------------------------------------------------------------------
+ Index Scan using tenk1_thous_tenthous on tenk1
+ Index Cond: ((thousand < 2) AND (tenthous = ANY ('{1001,3000}'::integer[])))
+(2 rows)
SELECT thousand, tenthous FROM tenk1
WHERE thousand < 2 AND tenthous IN (1001,3000)
@@ -1974,6 +1990,25 @@ ORDER BY thousand;
1 | 1001
(2 rows)
+explain (costs off)
+SELECT thousand, tenthous FROM tenk1
+WHERE thousand < 2 AND tenthous IN (1001,3000)
+ORDER BY thousand DESC, tenthous DESC;
+ QUERY PLAN
+--------------------------------------------------------------------------------
+ Index Scan Backward using tenk1_thous_tenthous on tenk1
+ Index Cond: ((thousand < 2) AND (tenthous = ANY ('{1001,3000}'::integer[])))
+(2 rows)
+
+SELECT thousand, tenthous FROM tenk1
+WHERE thousand < 2 AND tenthous IN (1001,3000)
+ORDER BY thousand DESC, tenthous DESC;
+ thousand | tenthous
+----------+----------
+ 1 | 1001
+ 0 | 3000
+(2 rows)
+
RESET enable_indexonlyscan;
--
-- Check elimination of constant-NULL subexpressions
diff --git a/src/test/regress/expected/join.out b/src/test/regress/expected/join.out
index 892ea5f17..f4939cd74 100644
--- a/src/test/regress/expected/join.out
+++ b/src/test/regress/expected/join.out
@@ -8620,10 +8620,9 @@ where j1.id1 % 1000 = 1 and j2.id1 % 1000 = 1 and j2.id1 >= any (array[1,5]);
Merge Cond: (j1.id1 = j2.id1)
Join Filter: (j2.id2 = j1.id2)
-> Index Scan using j1_id1_idx on j1
- -> Index Only Scan using j2_pkey on j2
+ -> Index Scan using j2_id1_idx on j2
Index Cond: (id1 >= ANY ('{1,5}'::integer[]))
- Filter: ((id1 % 1000) = 1)
-(7 rows)
+(6 rows)
select * from j1
inner join j2 on j1.id1 = j2.id1 and j1.id2 = j2.id2
diff --git a/src/test/regress/sql/create_index.sql b/src/test/regress/sql/create_index.sql
index d49ce9f30..41b955a27 100644
--- a/src/test/regress/sql/create_index.sql
+++ b/src/test/regress/sql/create_index.sql
@@ -753,7 +753,7 @@ SELECT count(*) FROM dupindexcols
WHERE f1 BETWEEN 'WA' AND 'ZZZ' and id < 1000 and f1 ~<~ 'YX';
--
--- Check ordering of =ANY indexqual results (bug in 9.2.0)
+-- Check that index scans with =ANY indexquals return rows in index order
--
explain (costs off)
@@ -774,6 +774,15 @@ SELECT thousand, tenthous FROM tenk1
WHERE thousand < 2 AND tenthous IN (1001,3000)
ORDER BY thousand;
+explain (costs off)
+SELECT thousand, tenthous FROM tenk1
+WHERE thousand < 2 AND tenthous IN (1001,3000)
+ORDER BY thousand DESC, tenthous DESC;
+
+SELECT thousand, tenthous FROM tenk1
+WHERE thousand < 2 AND tenthous IN (1001,3000)
+ORDER BY thousand DESC, tenthous DESC;
+
SET enable_indexonlyscan = OFF;
explain (costs off)
@@ -785,6 +794,15 @@ SELECT thousand, tenthous FROM tenk1
WHERE thousand < 2 AND tenthous IN (1001,3000)
ORDER BY thousand;
+explain (costs off)
+SELECT thousand, tenthous FROM tenk1
+WHERE thousand < 2 AND tenthous IN (1001,3000)
+ORDER BY thousand DESC, tenthous DESC;
+
+SELECT thousand, tenthous FROM tenk1
+WHERE thousand < 2 AND tenthous IN (1001,3000)
+ORDER BY thousand DESC, tenthous DESC;
+
RESET enable_indexonlyscan;
--
--
2.42.0
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan
2023-11-07 12:20 Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan Matthias van de Meent <[email protected]>
2023-11-08 01:53 ` Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan Peter Geoghegan <[email protected]>
@ 2023-11-09 23:57 ` Peter Geoghegan <[email protected]>
2023-11-10 02:05 ` Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan Matthias van de Meent <[email protected]>
1 sibling, 1 reply; 12+ messages in thread
From: Peter Geoghegan @ 2023-11-09 23:57 UTC (permalink / raw)
To: Matthias van de Meent <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>; Tom Lane <[email protected]>; Tomas Vondra <[email protected]>; Jeff Davis <[email protected]>; benoit <[email protected]>; Alexander Korotkov <[email protected]>
On Tue, Nov 7, 2023 at 5:53 PM Peter Geoghegan <[email protected]> wrote:
> If you end up finding a bug in this v6, it'll most likely be a case
> where nbtree fails to live up to that. This project is as much about
> robust/predictable performance as anything else -- nbtree needs to be
> able to cope with practically anything. I suggest that your review
> start by trying to break the patch along these lines.
I spent some time on this myself today (which I'd already planned on).
Attached is an adversarial stress-test, which shows something that
must be approaching the worst case for the patch in terms of time
spent with a buffer lock held, due to spending so much time evaluating
unusually expensive SAOP index quals. The array binary searches that
take place with a buffer lock held aren't quite like anything else
that nbtree can do right now, so it's worthy of special attention.
I thought of several factors that maximize both the number of binary
searches within any given _bt_readpage, as well as the cost of each
binary search -- the SQL file has full details. My test query is
*extremely* unrealistic, since it combines multiple independent
unrealistic factors, all of which aim to make life hard for the
implementation in one way or another. I hesitate to say that it
couldn't be much worse (I only spent a few hours on this), but I'm
prepared to say that it seems very unlikely that any real world query
could make the patch spend as many cycles in
_bt_readpage/_bt_checkkeys as this one does.
Perhaps you can think of some other factor that would make this test
case even less sympathetic towards the patch, Matthias? The only thing
I thought of that I've left out was the use of a custom btree opclass,
"unrealistically_slow_ops". Something that calls pg_usleep in its
order proc. (I left it out because it wouldn't prove anything.)
On my machine, custom instrumentation shows that each call to
_bt_readpage made while this query executes (on a patched server)
takes just under 1.4 milliseconds. While that is far longer than it
usually takes, it's basically acceptable IMV. It's not significantly
longer than I'd expect heap_index_delete_tuples() to take on an
average day with EBS (or other network-attached storage). But that's a
process that happens all the time, with an exclusive buffer lock held
on the leaf page throughout -- whereas this is only a shared buffer
lock, and involves a query that's just absurd .
Another factor that makes this seem acceptable is just how sensitive
the test case is to everything going exactly and perfectly wrong, all
at the same time, again and again. The test case uses a 32 column
index (the INDEX_MAX_KEYS maximum), with a query that has 32 SAOP
clauses (one per index column). If I reduce the number of SAOP clauses
in the query to (say) 8, I still have a test case that's almost as
silly as my original -- but now we only spend ~225 microseconds in
each _bt_readpage call (i.e. we spend over 6x less time in each
_bt_readpage call). (Admittedly if I also make the CREATE INDEX use
only 8 columns, we can fit more index tuples on one page, leaving us
at ~800 microseconds).
I'm a little surprised that it isn't a lot worse than this, given how
far I went. I was a little concerned that it would prove necessary to
lock this kind of thing down at some higher level (e.g., in the
planner), but that now looks unnecessary. There are much better ways
to DOS the server than this. For example, you could run this same
query while forcing a sequential scan! That appears to be quite a lot
less responsive to interrupts (in addition to being hopelessly slow),
probably because it uses parallel workers, each of which will use
wildly expensive filter quals that just do a linear scan of the SAOP.
--
Peter Geoghegan
Attachments:
[application/octet-stream] nemesis.sql (10.3K, ../../CAH2-Wzkq0ZA-G-W6AAVaD4GJmak4g4UkjgL+OtLyy-06mvCXjw@mail.gmail.com/2-nemesis.sql)
download
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan
2023-11-07 12:20 Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan Matthias van de Meent <[email protected]>
2023-11-08 01:53 ` Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan Peter Geoghegan <[email protected]>
2023-11-09 23:57 ` Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan Peter Geoghegan <[email protected]>
@ 2023-11-10 02:05 ` Matthias van de Meent <[email protected]>
0 siblings, 0 replies; 12+ messages in thread
From: Matthias van de Meent @ 2023-11-10 02:05 UTC (permalink / raw)
To: Peter Geoghegan <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>; Tom Lane <[email protected]>; Tomas Vondra <[email protected]>; Jeff Davis <[email protected]>; benoit <[email protected]>; Alexander Korotkov <[email protected]>
On Fri, 10 Nov 2023 at 00:58, Peter Geoghegan <[email protected]> wrote:
> On Tue, Nov 7, 2023 at 5:53 PM Peter Geoghegan <[email protected]> wrote:
> > If you end up finding a bug in this v6, it'll most likely be a case
> > where nbtree fails to live up to that. This project is as much about
> > robust/predictable performance as anything else -- nbtree needs to be
> > able to cope with practically anything. I suggest that your review
> > start by trying to break the patch along these lines.
>
> I spent some time on this myself today (which I'd already planned on).
>
> Attached is an adversarial stress-test, which shows something that
> must be approaching the worst case for the patch in terms of time
> spent with a buffer lock held, due to spending so much time evaluating
> unusually expensive SAOP index quals. The array binary searches that
> take place with a buffer lock held aren't quite like anything else
> that nbtree can do right now, so it's worthy of special attention.
>
> I thought of several factors that maximize both the number of binary
> searches within any given _bt_readpage, as well as the cost of each
> binary search -- the SQL file has full details. My test query is
> *extremely* unrealistic, since it combines multiple independent
> unrealistic factors, all of which aim to make life hard for the
> implementation in one way or another. I hesitate to say that it
> couldn't be much worse (I only spent a few hours on this), but I'm
> prepared to say that it seems very unlikely that any real world query
> could make the patch spend as many cycles in
> _bt_readpage/_bt_checkkeys as this one does.
>
> Perhaps you can think of some other factor that would make this test
> case even less sympathetic towards the patch, Matthias? The only thing
> I thought of that I've left out was the use of a custom btree opclass,
> "unrealistically_slow_ops". Something that calls pg_usleep in its
> order proc. (I left it out because it wouldn't prove anything.)
Have you tried using text index columns that are sorted with
non-default locales?
I've seen non-default locales use significantly more resources during
compare operations than any other ordering operation I know of (which
has mostly been in finding the locale), and use it extensively to test
improvements for worst index shapes over at my btree patchsets because
locales are dynamically loaded in text compare and nondefault locales
are not cached at all. I suspect that this would be even worse if a
somehow even worse locale path is available than what I'm using for
test right now; this could be the case with complex custom ICU
locales.
> On my machine, custom instrumentation shows that each call to
> _bt_readpage made while this query executes (on a patched server)
> takes just under 1.4 milliseconds. While that is far longer than it
> usually takes, it's basically acceptable IMV. It's not significantly
> longer than I'd expect heap_index_delete_tuples() to take on an
> average day with EBS (or other network-attached storage). But that's a
> process that happens all the time, with an exclusive buffer lock held
> on the leaf page throughout -- whereas this is only a shared buffer
> lock, and involves a query that's just absurd .
>
> Another factor that makes this seem acceptable is just how sensitive
> the test case is to everything going exactly and perfectly wrong, all
> at the same time, again and again. The test case uses a 32 column
> index (the INDEX_MAX_KEYS maximum), with a query that has 32 SAOP
> clauses (one per index column). If I reduce the number of SAOP clauses
> in the query to (say) 8, I still have a test case that's almost as
> silly as my original -- but now we only spend ~225 microseconds in
> each _bt_readpage call (i.e. we spend over 6x less time in each
> _bt_readpage call). (Admittedly if I also make the CREATE INDEX use
> only 8 columns, we can fit more index tuples on one page, leaving us
> at ~800 microseconds).
A quick update of the table definition to use the various installed
'fr-%-x-icu' locales on text hash columns instead of numeric with a
different collation for each column this gets me to EXPLAIN (analyze)
showing 2.07ms spent every buffer hit inside the index scan node, as
opposed to 1.76ms when using numeric. But, as you mention, the value
of this metric is probably not very high.
As for the patch itself, I'm probably about 50% through the patch now.
While reviewing, I noticed the following two user-visible items,
related to SAOP but not broken by or touched upon in this patch:
1. We don't seem to plan `column opr ALL (...)` as index conditions,
while this should be trivial to optimize for at least btree. Example:
SET enable_bitmapscan = OFF;
WITH a AS (select generate_series(1, 1000) a)
SELECT * FROM tenk1
WHERE thousand = ANY (array(table a))
AND thousand < ALL (array(table a));
This will never return any rows, but it does hit 9990 buffers in the
new btree code, while I expected that to be 0 buffers based on the
query and index (that is, I expected to hit 0 buffers, until I
realized that we don't push ALL into index filters). I shall assume
ALL isn't used all that often (heh), but it sure feels like we're
missing out on performance here.
2. We also don't seem to support array keys for row compares, which
probably is an even more niche use case:
SELECT count(*)
FROM tenk1
WHERE (thousand, tenthous) = ANY (ARRAY[(1, 1), (1, 2), (2, 1)]);
This is no different from master, too, but it'd be nice if there was
support for arrays of row operations, too, just so that composite
primary keys can also be looked up with SAOPs.
Kind regards,
Matthias van de Meent
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan
2023-11-07 12:20 Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan Matthias van de Meent <[email protected]>
2023-11-08 01:53 ` Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan Peter Geoghegan <[email protected]>
@ 2023-11-11 21:08 ` Matthias van de Meent <[email protected]>
2023-11-21 02:52 ` Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan Peter Geoghegan <[email protected]>
1 sibling, 1 reply; 12+ messages in thread
From: Matthias van de Meent @ 2023-11-11 21:08 UTC (permalink / raw)
To: Peter Geoghegan <[email protected]>; +Cc: Matthias van de Meent <[email protected]>; PostgreSQL Hackers <[email protected]>; Tom Lane <[email protected]>; Tomas Vondra <[email protected]>; Jeff Davis <[email protected]>; benoit <[email protected]>; Alexander Korotkov <[email protected]>
On Wed, 8 Nov 2023 at 02:53, Peter Geoghegan <[email protected]> wrote:
>
> On Tue, Nov 7, 2023 at 4:20 AM Matthias van de Meent
> <[email protected]> wrote:
> > On Tue, 7 Nov 2023 at 00:03, Peter Geoghegan <[email protected]> wrote:
> > > I should be able to post v6 later this week. My current plan is to
> > > commit the other nbtree patch first (the backwards scan "boundary
> > > cases" one from the ongoing CF) -- since I saw your review earlier
> > > today. I think that you should probably wait for this v6 before
> > > starting your review.
> >
> > Okay, thanks for the update, then I'll wait for v6 to be posted.
>
> On second thought, I'll just post v6 now (there won't be conflicts
> against the master branch once the other patch is committed anyway).
Thanks. Here's my review of the btree-related code:
> +++ b/src/backend/access/nbtree/nbtsearch.c
> @@ -1625,8 +1633,9 @@ _bt_readpage(IndexScanDesc scan, ScanDirection dir, OffsetNumber offnum)
> * set flag to true if all required keys are satisfied and false
> * otherwise.
> */
> - (void) _bt_checkkeys(scan, itup, indnatts, dir,
> - &requiredMatchedByPrecheck, false);
> + _bt_checkkeys(scan, &pstate, itup, false, false);
> + requiredMatchedByPrecheck = pstate.continuescan;
> + pstate.continuescan = true; /* reset */
The comment above the updated section needs to be updated.
> @@ -1625,8 +1633,9 @@ _bt_readpage(IndexScanDesc scan, ScanDirection dir, OffsetNumber offnum)
> * set flag to true if all required keys are satisfied and false
> * otherwise.
> */
> - (void) _bt_checkkeys(scan, itup, indnatts, dir,
> - &requiredMatchedByPrecheck, false);
> + _bt_checkkeys(scan, &pstate, itup, false, false);
This 'false' finaltup argument is surely wrong for the rightmost
page's rightmost tuple, no?
> +++ b/src/backend/access/nbtree/nbtutils.c
> @@ -357,6 +431,46 @@ _bt_preprocess_array_keys(IndexScanDesc scan)
> + /* We could pfree(elem_values) after, but not worth the cycles */
> + num_elems = _bt_merge_arrays(scan, cur,
> + (indoption[cur->sk_attno - 1] & INDOPTION_DESC) != 0,
> + prev->elem_values, prev->num_elems,
> + elem_values, num_elems);
This code can get hit several times when there are multiple = ANY
clauses, which may result in repeated leakage of these arrays during
this scan. I think cleaning up may well be worth the cycles when the
total size of the arrays is large enough.
> @@ -496,6 +627,48 @@ _bt_sort_array_elements(IndexScanDesc scan, ScanKey skey,
> _bt_compare_array_elements, &cxt);
> +_bt_merge_arrays(IndexScanDesc scan, ScanKey skey, bool reverse,
> + Datum *elems_orig, int nelems_orig,
> + Datum *elems_next, int nelems_next)
> [...]
> + /*
> + * Incrementally copy the original array into a temp buffer, skipping over
> + * any items that are missing from the "next" array
> + */
Given that we only keep the members that both arrays have in common,
the result array will be a strict subset of the original array. So, I
don't quite see why we need the temporary buffer here - we can reuse
the entries of the elems_orig array that we've already compared
against the elems_next array.
We may want to optimize this further by iterating over only the
smallest array: With the current code, [1, 2] + [1....1000] is faster
to merge than [1..1000] + [1000, 1001], because 2 * log(1000) is much
smaller than 1000*log(2). In practice this may matter very little,
though.
An even better optimized version would do a merge join on the two
arrays, rather than loop + binary search.
> @@ -515,6 +688,161 @@ _bt_compare_array_elements(const void *a, const void *b, void *arg)
> [...]
> +_bt_binsrch_array_skey(FmgrInfo *orderproc,
Is there a reason for this complex initialization of high/low_elem,
rather than the this easier to understand and more compact
initialization?:
+ low_elem = 0;
+ high_elem = array->num_elems - 1;
+ if (cur_elem_start)
+ {
+ if (ScanDirectionIsForward(dir))
+ low_elem = array->cur_elem;
+ else
+ high_elem = array->cur_elem;
+ }
> @@ -661,20 +1008,691 @@ _bt_restore_array_keys(IndexScanDesc scan)
> [...]
> + _bt_array_keys_remain(IndexScanDesc scan, ScanDirection dir)
> [...]
> + if (scan->parallel_scan != NULL)
> + _bt_parallel_done(scan);
> +
> + /*
> + * No more primitive index scans. Terminate the top-level scan.
> + */
> + return false;
I think the conditional _bt_parallel_done(scan) feels misplaced here,
as the comment immediately below indicates the scan is to be
terminated after that comment. So, either move this _bt_parallel_done
call outside the function (which by name would imply it is read-only,
without side effects like this) or move it below the comment
"terminate the top-level scan".
> +_bt_advance_array_keys(IndexScanDesc scan, BTReadPageState *pstate,
> [...]
> + * Set up ORDER 3-way comparison function and array state
> [...]
> + * Optimization: Skip over non-required scan keys when we know that
These two sections should probably be swapped, as the skip makes the
setup useless.
Also, the comment here is wrong; the scan keys that are skipped are
'required', not 'non-required'.
> +++ b/src/test/regress/expected/join.out
> @@ -8620,10 +8620,9 @@ where j1.id1 % 1000 = 1 and j2.id1 % 1000 = 1 and j2.id1 >= any (array[1,5]);
> Merge Cond: (j1.id1 = j2.id1)
> Join Filter: (j2.id2 = j1.id2)
> -> Index Scan using j1_id1_idx on j1
> - -> Index Only Scan using j2_pkey on j2
> + -> Index Scan using j2_id1_idx on j2
> Index Cond: (id1 >= ANY ('{1,5}'::integer[]))
> - Filter: ((id1 % 1000) = 1)
> -(7 rows)
> +(6 rows)
I'm a bit surprised that we don't have the `id1 % 1000 = 1` filter
anymore. The output otherwise matches (quite possibly because the
other join conditions don't match) and I don't have time to
investigate the intricacies between IOS vs normal IS, but this feels
off.
----
As for the planner changes, I don't think I'm familiar enough with the
planner to make any authorative comments on this. However, it does
look like you've changed the meaning of 'amsearcharray', and I'm not
sure it's OK to assume all indexes that support amsearcharray will
also support for this new assumption of ordered retrieval of SAOPs.
For one, the pgroonga extension [0] does mark
amcanorder+amsearcharray.
Kind regards,
Matthias van de Meent
Neon (https://neon.tech)
[0] https://github.com/pgroonga/pgroonga/blob/115414723c7eb8ce9eb667da98e008bd10fbae0a/src/pgroonga.c#L8...
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan
2023-11-07 12:20 Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan Matthias van de Meent <[email protected]>
2023-11-08 01:53 ` Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan Peter Geoghegan <[email protected]>
2023-11-11 21:08 ` Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan Matthias van de Meent <[email protected]>
@ 2023-11-21 02:52 ` Peter Geoghegan <[email protected]>
2023-11-27 13:39 ` Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan Heikki Linnakangas <[email protected]>
2023-11-28 12:29 ` Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan Tomas Vondra <[email protected]>
2023-12-09 18:38 ` Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan Peter Geoghegan <[email protected]>
0 siblings, 3 replies; 12+ messages in thread
From: Peter Geoghegan @ 2023-11-21 02:52 UTC (permalink / raw)
To: Matthias van de Meent <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>; Tom Lane <[email protected]>; Tomas Vondra <[email protected]>; Jeff Davis <[email protected]>; benoit <[email protected]>; Alexander Korotkov <[email protected]>
On Sat, Nov 11, 2023 at 1:08 PM Matthias van de Meent
<[email protected]> wrote:
> Thanks. Here's my review of the btree-related code:
Attached is v7.
The main focus in v7 is making the handling of required
inequality-strategy scan keys more explicit -- now there is an
understanding of inequalities shared by _bt_check_compare (the
function that becomes the guts of _bt_checkkeys) and the new
_bt_advance_array_keys function/state machine. The big idea for v7 is
to generalize how we handle required equality-strategy scan keys
(always required in both scan directions), extending the same concept
to deal with required inequality strategy scan keys (only ever
required in one direction, which may or may not be the scan
direction).
This led to my discovering and fixing a couple of bugs related to
inequality handling. These issues were of the same general character
as many others I've dealt with before now: they involved subtle
confusion about when and how to start another primitive index scan,
leading to the scan reading many more pages than strictly necessary
(potentially many more than master). In other words, cases where we
didn't give up and start another primitive index scan, even though
(with a repro of the issue) it's obviously not sensible. An accidental
full index scan.
While I'm still not completely happy with the way that inequalities
are handled, things in this area are much improved in v7.
It should be noted that the patch isn't strictly guaranteed to always
read fewer index pages than master, for a given query plan and index.
This is by design. Though the patch comes close, it's not quite a
certainty. There are known cases where the patch reads the occasional
extra page (relative to what master would have done under the same
circumstances). These are cases where the implementation just cannot
know for sure whether the next/sibling leaf page has key space covered
by any of the scan's array keys (at least not in a way that seems
practical). The implementation has simple heuristics that infer (a
polite word for "make an educated guess") about what will be found on
the next page. Theoretically we could be more conservative in how we
go about this, but that seems like a bad idea to me. It's really easy
to find cases where the maximally conservative approach loses by a
lot, and really hard to show cases where it wins at all.
These heuristics are more or less a limited form of the heuristics
that skip scan would need. A *very* limited form. We're still
conservative. Here's how it works, at a high level: if the scan can
make it all the way to the end of the page without having to start a
new primitive index scan (before reaching the end), and then finds
that "finaltup" itself (which is usually the page high key) advances
the array keys, we speculate: we move on to the sibling page. It's
just about possible that we'll discover (once on the next page) that
finaltup actually advanced the array keys by so much (in one single
advancement step) that the current/new keys cover key space beyond the
sibling page we just arrived at. The sibling page access will have
been wasted (though I prefer to think of it as a cost of doing
business).
I go into a lot of detail on the trade-offs in this area in comments
at the end of the new _bt_checkkeys(), just after it calls
_bt_advance_array_keys(). Hopefully this is reasonably clear. It's
always much easier to understand these things when you've written lots
of test cases, though. So I wouldn't at all be surprised to hear that
my explanation needs more work. I suspect that I'm spending more time
on the topic than it actually warrants, but you have to spend a lot of
time on it for yourself to be able to see why that is.
> > +++ b/src/backend/access/nbtree/nbtsearch.c
> > @@ -1625,8 +1633,9 @@ _bt_readpage(IndexScanDesc scan, ScanDirection dir, OffsetNumber offnum)
> > * set flag to true if all required keys are satisfied and false
> > * otherwise.
> > */
> > - (void) _bt_checkkeys(scan, itup, indnatts, dir,
> > - &requiredMatchedByPrecheck, false);
> > + _bt_checkkeys(scan, &pstate, itup, false, false);
> > + requiredMatchedByPrecheck = pstate.continuescan;
> > + pstate.continuescan = true; /* reset */
>
> The comment above the updated section needs to be updated.
Updated.
> > @@ -1625,8 +1633,9 @@ _bt_readpage(IndexScanDesc scan, ScanDirection dir, OffsetNumber offnum)
> > * set flag to true if all required keys are satisfied and false
> > * otherwise.
> > */
> > - (void) _bt_checkkeys(scan, itup, indnatts, dir,
> > - &requiredMatchedByPrecheck, false);
> > + _bt_checkkeys(scan, &pstate, itup, false, false);
>
> This 'false' finaltup argument is surely wrong for the rightmost
> page's rightmost tuple, no?
Not in any practical sense. Since finaltup means "the tuple that you
should use to decide whether to go to the next page or not", and a
rightmost page doesn't have a next page.
There are exactly two ways that the top-level scan can end (not to be
confused with the primitive scan), at least in v7. They are:
1. The state machine can exhaust the scan's array keys, ending the
top-level scan.
2. The scan can just run out of pages, without ever running out of
array keys (some array keys can sort higher than any real value from
the index). This is just like how an index scan ends when it lacks any
required scan keys to terminate the scan, and eventually runs out of
pages to scan (think of an index-only scan that performs a full scan
of the index, feeding into a group aggregate).
Note that it wouldn't be okay if the design relied on _bt_checkkeys
advancing and exhausting the array keys -- we really do need both 1
and 2 to deal with various edge cases. For example, there is no way
that we'll ever be able to call _bt_checkkeys with a completely empty
index. It simply doesn't have any tuples at all. In fact, it doesn't
even have any pages (apart from the metapage), so clearly we can't
expect any calls to _bt_readpage (much less _bt_checkkeys).
> > +++ b/src/backend/access/nbtree/nbtutils.c
> > @@ -357,6 +431,46 @@ _bt_preprocess_array_keys(IndexScanDesc scan)
> > + /* We could pfree(elem_values) after, but not worth the cycles */
> > + num_elems = _bt_merge_arrays(scan, cur,
> > + (indoption[cur->sk_attno - 1] & INDOPTION_DESC) != 0,
> > + prev->elem_values, prev->num_elems,
> > + elem_values, num_elems);
>
> This code can get hit several times when there are multiple = ANY
> clauses, which may result in repeated leakage of these arrays during
> this scan. I think cleaning up may well be worth the cycles when the
> total size of the arrays is large enough.
They won't leak because the memory is allocated in the same dedicated
memory context.
That said, I added a pfree(). It couldn't hurt.
> > @@ -496,6 +627,48 @@ _bt_sort_array_elements(IndexScanDesc scan, ScanKey skey,
> > _bt_compare_array_elements, &cxt);
> > +_bt_merge_arrays(IndexScanDesc scan, ScanKey skey, bool reverse,
> > + Datum *elems_orig, int nelems_orig,
> > + Datum *elems_next, int nelems_next)
> > [...]
> > + /*
> > + * Incrementally copy the original array into a temp buffer, skipping over
> > + * any items that are missing from the "next" array
> > + */
>
> Given that we only keep the members that both arrays have in common,
> the result array will be a strict subset of the original array. So, I
> don't quite see why we need the temporary buffer here - we can reuse
> the entries of the elems_orig array that we've already compared
> against the elems_next array.
This code path is only hit when the query was written on autopilot,
since it must have contained redundant SAOPs for the same index column
-- a glaring inconsistency. Plus these arrays just aren't very big in
practice (despite my concerns about huge arrays). Plus there is only
one of these array-specific preprocessing steps per btrescan. So I
don't think that it's worth going to too much trouble here.
> We may want to optimize this further by iterating over only the
> smallest array: With the current code, [1, 2] + [1....1000] is faster
> to merge than [1..1000] + [1000, 1001], because 2 * log(1000) is much
> smaller than 1000*log(2). In practice this may matter very little,
> though.
> An even better optimized version would do a merge join on the two
> arrays, rather than loop + binary search.
v7 allocates the temp buffer using the size of whatever array is the
smaller of the two, just because it's an easy marginal improvement.
> > @@ -515,6 +688,161 @@ _bt_compare_array_elements(const void *a, const void *b, void *arg)
> > [...]
> > +_bt_binsrch_array_skey(FmgrInfo *orderproc,
>
> Is there a reason for this complex initialization of high/low_elem,
> rather than the this easier to understand and more compact
> initialization?:
>
> + low_elem = 0;
> + high_elem = array->num_elems - 1;
> + if (cur_elem_start)
> + {
> + if (ScanDirectionIsForward(dir))
> + low_elem = array->cur_elem;
> + else
> + high_elem = array->cur_elem;
> + }
I agree that it's better your way. Done that way in v7.
> I think the conditional _bt_parallel_done(scan) feels misplaced here,
> as the comment immediately below indicates the scan is to be
> terminated after that comment. So, either move this _bt_parallel_done
> call outside the function (which by name would imply it is read-only,
> without side effects like this) or move it below the comment
> "terminate the top-level scan".
v7 moves the comment up, so that it's just before the _bt_parallel_done() call.
> > +_bt_advance_array_keys(IndexScanDesc scan, BTReadPageState *pstate,
> > [...]
> > + * Set up ORDER 3-way comparison function and array state
> > [...]
> > + * Optimization: Skip over non-required scan keys when we know that
>
> These two sections should probably be swapped, as the skip makes the
> setup useless.
Not quite: we need to increment arrayidx for later loop iterations/scan keys.
> Also, the comment here is wrong; the scan keys that are skipped are
> 'required', not 'non-required'.
Agreed. Fixed.
> > +++ b/src/test/regress/expected/join.out
> > @@ -8620,10 +8620,9 @@ where j1.id1 % 1000 = 1 and j2.id1 % 1000 = 1 and j2.id1 >= any (array[1,5]);
> > Merge Cond: (j1.id1 = j2.id1)
> > Join Filter: (j2.id2 = j1.id2)
> > -> Index Scan using j1_id1_idx on j1
> > - -> Index Only Scan using j2_pkey on j2
> > + -> Index Scan using j2_id1_idx on j2
> > Index Cond: (id1 >= ANY ('{1,5}'::integer[]))
> > - Filter: ((id1 % 1000) = 1)
> > -(7 rows)
> > +(6 rows)
>
> I'm a bit surprised that we don't have the `id1 % 1000 = 1` filter
> anymore. The output otherwise matches (quite possibly because the
> other join conditions don't match) and I don't have time to
> investigate the intricacies between IOS vs normal IS, but this feels
> off.
This happens because the new plan uses a completely different index --
which happens to be a partial index whose predicate exactly matches
the old plan's filter quals. That factor makes the filter quals
unnecessary. That's all this is.
> As for the planner changes, I don't think I'm familiar enough with the
> planner to make any authorative comments on this. However, it does
> look like you've changed the meaning of 'amsearcharray', and I'm not
> sure it's OK to assume all indexes that support amsearcharray will
> also support for this new assumption of ordered retrieval of SAOPs.
> For one, the pgroonga extension [0] does mark
> amcanorder+amsearcharray.
The changes that I've made to the planner are subtractive. We more or
less go back to how things were just after the initial work on nbtree
amsearcharray support. That work was (at least tacitly) assumed to
have no impact on ordered scans. Because why should it? What other
type of index clause has ever affected what seems like a rather
unrelated thing (namely the sort order of the scan)? The oversight was
understandable. The kinds of plans that master cannot produce output
for in standard index order are really silly plans, independent of
this issue; it makes zero sense to allow a non-required array scan key
to affect how or when we skip.
The code that I'm removing from the planner is code that quite
obviously assumes nbtree-like behavior. So I'm taking away code like
that, rather than adding new code like that. That said, I am really
surprised that any extension creates an index AM amcanorder=true (not
to be confused with amcanorderbyop=true, which is less surprising).
That means that it promises the planner that it behaves just like
nbtree. To quote the docs, it must have "btree-compatible strategy
numbers for their [its] equality and ordering operators". Is that
really something that pgroonga even attempts? And if so, why?
I also find it bizarre that pgroonga's handler-stated capabilities
include "amcanunique=true". So pgroonga is a full text search engine,
but also supports unique indexes? I find that particularly hard to
believe, and suspect that the way that they set things up in the AM
handler just isn't very well thought out.
--
Peter Geoghegan
Attachments:
[application/octet-stream] v7-0001-Enhance-nbtree-ScalarArrayOp-execution.patch (126.7K, ../../CAH2-WzmTHoCsOmSgLg=yyft9LoERtuCKXyG2GZn+28PzonFA_g@mail.gmail.com/2-v7-0001-Enhance-nbtree-ScalarArrayOp-execution.patch)
download | inline diff:
From 8e3db71c09aa1ecad1a90a9ec8b4cdbd38c37097 Mon Sep 17 00:00:00 2001
From: Peter Geoghegan <[email protected]>
Date: Sat, 17 Jun 2023 17:03:36 -0700
Subject: [PATCH v7] Enhance nbtree ScalarArrayOp execution.
Commit 9e8da0f7 taught nbtree to handle ScalarArrayOpExpr quals
natively. This works by pushing down the full context (the array keys)
to the nbtree index AM, enabling it to execute multiple primitive index
scans that the planner treats as one continuous index scan/index path.
This earlier enhancement enabled nbtree ScalarArrayOp index-only scans.
It also allowed scans with ScalarArrayOp quals to return ordered results
(with some notable restrictions, described further down).
Take this general approach a lot further: teach nbtree SAOP index scans
to determine how best to execute ScalarArrayOp scans (how many primitive
index scans to use under the hood) by applying information about the
physical characteristics of the index at runtime. This approach can be
far more efficient. Many cases that previously required thousands of
index descents now require as few as one single index descent. And, all
SAOP scans reliably avoid duplicative leaf page accesses (just like any
other nbtree index scan).
The array state machine now advances using binary searches for the array
element that best matches the next tuple's attribute value. This whole
process makes required scan key arrays (i.e. arrays from scan keys that
can terminate the scan) ratchet forward in lockstep with the index scan.
Non-required arrays (i.e. arrays from scan keys that can only exclude
non-matching tuples) are for the most part advanced via this same search
process. We just can't assume a fixed relationship between the current
element of any non-required array and the progress of the index scan
through the index's key space (that would be wrong).
Naturally, only required SAOP scan keys trigger skipping over leaf pages
(non-required arrays cannot safely end or start primitive index scans).
Consequently, index scans of a composite index with (say) a high-order
inequality scan key (which we'll mark required) and a low-order SAOP
scan key (which we'll mark non-required) will now reliably output rows
in index order. Such scans are always executed as one large index scan
under the hood, which is obviously the most efficient way to do it, for
the usual reason (no more wasting cycles on repeat leaf page accesses).
Generalizing SAOP execution along these lines removes any question of
index scans outputting tuples in any order that isn't the index's order.
This allow us to remove various special cases from the planner -- which
in turn makes the nbtree work more widely applicable and more effective.
Bugfix commit 807a40c5 taught the planner to avoid generating unsafe
path keys: path keys on a multicolumn index path, with a SAOP clause on
any attribute beyond the first/most significant attribute. These cases
are now all safe, so we go back to generating path keys without regard
for the presence of SAOP clauses (just like with any other clause type).
Also undo changes from follow-up bugfix commit a4523c5a, which taught
the planner to produce alternative index paths without any low-order
ScalarArrayOpExpr quals (making the SAOP quals into filter quals).
We'll no longer generate these alternative paths, which can no longer
offer any advantage over the index qual paths that we do still generate.
Affected queries thereby avoid all of the disadvantages that come from
using filter quals within index scan nodes. In particular, they can
avoid the extra heap page accesses previously incurred when using filter
quals to exclude non-matching tuples (index quals can be used instead).
This shift is expected to be fairly common in real world applications,
especially with queries that have multiple SAOPs that can now all be
used as index quals when scanning a composite index. Queries with
low-order SAOPs (especially non-required ones) are also likely to see a
significant reduction in heap page accesses.
Author: Peter Geoghegan <[email protected]>
Reviewed-By: Matthias van de Meent <[email protected]>
Discussion: https://postgr.es/m/CAH2-Wz=ksvN_sjcnD1+Bt-WtifRA5ok48aDYnq3pkKhxgMQpcw@mail.gmail.com
---
src/include/access/nbtree.h | 42 +-
src/backend/access/nbtree/nbtree.c | 63 +-
src/backend/access/nbtree/nbtsearch.c | 84 +-
src/backend/access/nbtree/nbtutils.c | 1727 +++++++++++++++++++-
src/backend/optimizer/path/indxpath.c | 86 +-
src/backend/utils/adt/selfuncs.c | 122 +-
doc/src/sgml/monitoring.sgml | 13 +
src/test/regress/expected/create_index.out | 61 +-
src/test/regress/expected/join.out | 5 +-
src/test/regress/sql/create_index.sql | 20 +-
10 files changed, 1932 insertions(+), 291 deletions(-)
diff --git a/src/include/access/nbtree.h b/src/include/access/nbtree.h
index 7bfbf3086..566e1c15d 100644
--- a/src/include/access/nbtree.h
+++ b/src/include/access/nbtree.h
@@ -965,7 +965,7 @@ typedef struct BTScanPosData
* moreLeft and moreRight track whether we think there may be matching
* index entries to the left and right of the current page, respectively.
* We can clear the appropriate one of these flags when _bt_checkkeys()
- * returns continuescan = false.
+ * sets BTReadPageState.continuescan = false.
*/
bool moreLeft;
bool moreRight;
@@ -1043,13 +1043,13 @@ typedef struct BTScanOpaqueData
/* workspace for SK_SEARCHARRAY support */
ScanKey arrayKeyData; /* modified copy of scan->keyData */
- bool arraysStarted; /* Started array keys, but have yet to "reach
- * past the end" of all arrays? */
int numArrayKeys; /* number of equality-type array keys (-1 if
* there are any unsatisfiable array keys) */
- int arrayKeyCount; /* count indicating number of array scan keys
- * processed */
+ bool needPrimScan; /* Perform another primitive scan? */
BTArrayKeyInfo *arrayKeys; /* info about each equality-type array key */
+ FmgrInfo *orderProcs; /* ORDER procs for equality constraint keys */
+ int numPrimScans; /* Running tally of # primitive index scans
+ * (used to coordinate parallel workers) */
MemoryContext arrayContext; /* scan-lifespan context for array data */
/* info about killed items if any (killedItems is NULL if never used) */
@@ -1083,6 +1083,29 @@ typedef struct BTScanOpaqueData
typedef BTScanOpaqueData *BTScanOpaque;
+/*
+ * _bt_readpage state used across _bt_checkkeys calls for a page
+ *
+ * When _bt_readpage is called during a forward scan that has one or more
+ * equality-type SK_SEARCHARRAY scan keys, it has an extra responsibility: to
+ * set up information about the final tuple from the page. This must happen
+ * before the first call to _bt_checkkeys. _bt_checkkeys uses the final tuple
+ * to manage advancement of the scan's array keys more efficiently.
+ */
+typedef struct BTReadPageState
+{
+ /* Input parameters, set by _bt_readpage */
+ ScanDirection dir; /* current scan direction */
+ IndexTuple finaltup; /* final tuple (high key for forward scans) */
+
+ /* Output parameters, set by _bt_checkkeys */
+ bool continuescan; /* Terminate ongoing (primitive) index scan? */
+
+ /* Private _bt_checkkeys-managed state */
+ bool finaltupchecked; /* final tuple checked against current
+ * SK_SEARCHARRAY array keys? */
+} BTReadPageState;
+
/*
* We use some private sk_flags bits in preprocessed scan keys. We're allowed
* to use bits 16-31 (see skey.h). The uppermost bits are copied from the
@@ -1090,6 +1113,7 @@ typedef BTScanOpaqueData *BTScanOpaque;
*/
#define SK_BT_REQFWD 0x00010000 /* required to continue forward scan */
#define SK_BT_REQBKWD 0x00020000 /* required to continue backward scan */
+#define SK_BT_RDDNARRAY 0x00040000 /* redundant in array preprocessing */
#define SK_BT_INDOPTION_SHIFT 24 /* must clear the above bits */
#define SK_BT_DESC (INDOPTION_DESC << SK_BT_INDOPTION_SHIFT)
#define SK_BT_NULLS_FIRST (INDOPTION_NULLS_FIRST << SK_BT_INDOPTION_SHIFT)
@@ -1160,7 +1184,7 @@ extern bool btcanreturn(Relation index, int attno);
extern bool _bt_parallel_seize(IndexScanDesc scan, BlockNumber *pageno);
extern void _bt_parallel_release(IndexScanDesc scan, BlockNumber scan_page);
extern void _bt_parallel_done(IndexScanDesc scan);
-extern void _bt_parallel_advance_array_keys(IndexScanDesc scan);
+extern void _bt_parallel_next_primitive_scan(IndexScanDesc scan);
/*
* prototypes for functions in nbtdedup.c
@@ -1253,12 +1277,12 @@ extern BTScanInsert _bt_mkscankey(Relation rel, IndexTuple itup);
extern void _bt_freestack(BTStack stack);
extern void _bt_preprocess_array_keys(IndexScanDesc scan);
extern void _bt_start_array_keys(IndexScanDesc scan, ScanDirection dir);
-extern bool _bt_advance_array_keys(IndexScanDesc scan, ScanDirection dir);
+extern bool _bt_array_keys_remain(IndexScanDesc scan, ScanDirection dir);
extern void _bt_mark_array_keys(IndexScanDesc scan);
extern void _bt_restore_array_keys(IndexScanDesc scan);
extern void _bt_preprocess_keys(IndexScanDesc scan);
-extern bool _bt_checkkeys(IndexScanDesc scan, IndexTuple tuple,
- int tupnatts, ScanDirection dir, bool *continuescan,
+extern bool _bt_checkkeys(IndexScanDesc scan, BTReadPageState *pstate,
+ IndexTuple tuple, bool finaltup,
bool requiredMatchedByPrecheck);
extern void _bt_killitems(IndexScanDesc scan);
extern BTCycleId _bt_vacuum_cycleid(Relation rel);
diff --git a/src/backend/access/nbtree/nbtree.c b/src/backend/access/nbtree/nbtree.c
index a88b36a58..6328a8a63 100644
--- a/src/backend/access/nbtree/nbtree.c
+++ b/src/backend/access/nbtree/nbtree.c
@@ -48,8 +48,8 @@
* BTPARALLEL_IDLE indicates that no backend is currently advancing the scan
* to a new page; some process can start doing that.
*
- * BTPARALLEL_DONE indicates that the scan is complete (including error exit).
- * We reach this state once for every distinct combination of array keys.
+ * BTPARALLEL_DONE indicates that the primitive index scan is complete
+ * (including error exit). Reached once per primitive index scan.
*/
typedef enum
{
@@ -69,8 +69,8 @@ typedef struct BTParallelScanDescData
BTPS_State btps_pageStatus; /* indicates whether next page is
* available for scan. see above for
* possible states of parallel scan. */
- int btps_arrayKeyCount; /* count indicating number of array scan
- * keys processed by parallel scan */
+ int btps_numPrimScans; /* count indicating number of primitive
+ * index scans (used with array keys) */
slock_t btps_mutex; /* protects above variables */
ConditionVariable btps_cv; /* used to synchronize parallel scan */
} BTParallelScanDescData;
@@ -275,8 +275,8 @@ btgettuple(IndexScanDesc scan, ScanDirection dir)
/* If we have a tuple, return it ... */
if (res)
break;
- /* ... otherwise see if we have more array keys to deal with */
- } while (so->numArrayKeys && _bt_advance_array_keys(scan, dir));
+ /* ... otherwise see if we need another primitive index scan */
+ } while (so->numArrayKeys && _bt_array_keys_remain(scan, dir));
return res;
}
@@ -333,8 +333,8 @@ btgetbitmap(IndexScanDesc scan, TIDBitmap *tbm)
ntids++;
}
}
- /* Now see if we have more array keys to deal with */
- } while (so->numArrayKeys && _bt_advance_array_keys(scan, ForwardScanDirection));
+ /* Now see if we need another primitive index scan */
+ } while (so->numArrayKeys && _bt_array_keys_remain(scan, ForwardScanDirection));
return ntids;
}
@@ -364,9 +364,10 @@ btbeginscan(Relation rel, int nkeys, int norderbys)
so->keyData = NULL;
so->arrayKeyData = NULL; /* assume no array keys for now */
- so->arraysStarted = false;
so->numArrayKeys = 0;
+ so->needPrimScan = false;
so->arrayKeys = NULL;
+ so->orderProcs = NULL;
so->arrayContext = NULL;
so->killedItems = NULL; /* until needed */
@@ -406,7 +407,8 @@ btrescan(IndexScanDesc scan, ScanKey scankey, int nscankeys,
}
so->markItemIndex = -1;
- so->arrayKeyCount = 0;
+ so->needPrimScan = false;
+ so->numPrimScans = 0;
so->firstPage = false;
BTScanPosUnpinIfPinned(so->markPos);
BTScanPosInvalidate(so->markPos);
@@ -588,7 +590,7 @@ btinitparallelscan(void *target)
SpinLockInit(&bt_target->btps_mutex);
bt_target->btps_scanPage = InvalidBlockNumber;
bt_target->btps_pageStatus = BTPARALLEL_NOT_INITIALIZED;
- bt_target->btps_arrayKeyCount = 0;
+ bt_target->btps_numPrimScans = 0;
ConditionVariableInit(&bt_target->btps_cv);
}
@@ -614,7 +616,7 @@ btparallelrescan(IndexScanDesc scan)
SpinLockAcquire(&btscan->btps_mutex);
btscan->btps_scanPage = InvalidBlockNumber;
btscan->btps_pageStatus = BTPARALLEL_NOT_INITIALIZED;
- btscan->btps_arrayKeyCount = 0;
+ btscan->btps_numPrimScans = 0;
SpinLockRelease(&btscan->btps_mutex);
}
@@ -625,7 +627,11 @@ btparallelrescan(IndexScanDesc scan)
*
* The return value is true if we successfully seized the scan and false
* if we did not. The latter case occurs if no pages remain for the current
- * set of scankeys.
+ * primitive index scan.
+ *
+ * When array scan keys are in use, each worker process independently advances
+ * its array keys. It's crucial that each worker process never be allowed to
+ * scan a page from before the current scan position.
*
* If the return value is true, *pageno returns the next or current page
* of the scan (depending on the scan direction). An invalid block number
@@ -656,16 +662,17 @@ _bt_parallel_seize(IndexScanDesc scan, BlockNumber *pageno)
SpinLockAcquire(&btscan->btps_mutex);
pageStatus = btscan->btps_pageStatus;
- if (so->arrayKeyCount < btscan->btps_arrayKeyCount)
+ if (so->numPrimScans < btscan->btps_numPrimScans)
{
- /* Parallel scan has already advanced to a new set of scankeys. */
+ /* Top-level scan already moved on to next primitive index scan */
status = false;
}
else if (pageStatus == BTPARALLEL_DONE)
{
/*
- * We're done with this set of scankeys. This may be the end, or
- * there could be more sets to try.
+ * We're done with this primitive index scan. This might have
+ * been the final primitive index scan required, or the top-level
+ * index scan might require additional primitive scans.
*/
status = false;
}
@@ -697,9 +704,12 @@ _bt_parallel_seize(IndexScanDesc scan, BlockNumber *pageno)
void
_bt_parallel_release(IndexScanDesc scan, BlockNumber scan_page)
{
+ BTScanOpaque so PG_USED_FOR_ASSERTS_ONLY = (BTScanOpaque) scan->opaque;
ParallelIndexScanDesc parallel_scan = scan->parallel_scan;
BTParallelScanDesc btscan;
+ Assert(!so->needPrimScan);
+
btscan = (BTParallelScanDesc) OffsetToPointer((void *) parallel_scan,
parallel_scan->ps_offset);
@@ -733,12 +743,11 @@ _bt_parallel_done(IndexScanDesc scan)
parallel_scan->ps_offset);
/*
- * Mark the parallel scan as done for this combination of scan keys,
- * unless some other process already did so. See also
- * _bt_advance_array_keys.
+ * Mark the primitive index scan as done, unless some other process
+ * already did so. See also _bt_array_keys_remain.
*/
SpinLockAcquire(&btscan->btps_mutex);
- if (so->arrayKeyCount >= btscan->btps_arrayKeyCount &&
+ if (so->numPrimScans >= btscan->btps_numPrimScans &&
btscan->btps_pageStatus != BTPARALLEL_DONE)
{
btscan->btps_pageStatus = BTPARALLEL_DONE;
@@ -752,14 +761,14 @@ _bt_parallel_done(IndexScanDesc scan)
}
/*
- * _bt_parallel_advance_array_keys() -- Advances the parallel scan for array
- * keys.
+ * _bt_parallel_next_primitive_scan() -- Advances parallel primitive scan
+ * counter when array keys are in use.
*
- * Updates the count of array keys processed for both local and parallel
+ * Updates the count of primitive index scans for both local and parallel
* scans.
*/
void
-_bt_parallel_advance_array_keys(IndexScanDesc scan)
+_bt_parallel_next_primitive_scan(IndexScanDesc scan)
{
BTScanOpaque so = (BTScanOpaque) scan->opaque;
ParallelIndexScanDesc parallel_scan = scan->parallel_scan;
@@ -768,13 +777,13 @@ _bt_parallel_advance_array_keys(IndexScanDesc scan)
btscan = (BTParallelScanDesc) OffsetToPointer((void *) parallel_scan,
parallel_scan->ps_offset);
- so->arrayKeyCount++;
+ so->numPrimScans++;
SpinLockAcquire(&btscan->btps_mutex);
if (btscan->btps_pageStatus == BTPARALLEL_DONE)
{
btscan->btps_scanPage = InvalidBlockNumber;
btscan->btps_pageStatus = BTPARALLEL_NOT_INITIALIZED;
- btscan->btps_arrayKeyCount++;
+ btscan->btps_numPrimScans++;
}
SpinLockRelease(&btscan->btps_mutex);
}
diff --git a/src/backend/access/nbtree/nbtsearch.c b/src/backend/access/nbtree/nbtsearch.c
index efc5284e5..834012514 100644
--- a/src/backend/access/nbtree/nbtsearch.c
+++ b/src/backend/access/nbtree/nbtsearch.c
@@ -893,7 +893,7 @@ _bt_first(IndexScanDesc scan, ScanDirection dir)
*/
if (!so->qual_ok)
{
- /* Notify any other workers that we're done with this scan key. */
+ /* Notify any other workers that this primitive scan is done */
_bt_parallel_done(scan);
return false;
}
@@ -1537,9 +1537,9 @@ _bt_readpage(IndexScanDesc scan, ScanDirection dir, OffsetNumber offnum)
BTPageOpaque opaque;
OffsetNumber minoff;
OffsetNumber maxoff;
- int itemIndex;
- bool continuescan;
- int indnatts;
+ BTReadPageState pstate;
+ int numArrayKeys,
+ itemIndex;
bool requiredMatchedByPrecheck;
/*
@@ -1560,8 +1560,12 @@ _bt_readpage(IndexScanDesc scan, ScanDirection dir, OffsetNumber offnum)
_bt_parallel_release(scan, BufferGetBlockNumber(so->currPos.buf));
}
- continuescan = true; /* default assumption */
- indnatts = IndexRelationGetNumberOfAttributes(scan->indexRelation);
+ pstate.dir = dir;
+ pstate.finaltup = NULL;
+ pstate.continuescan = true; /* default assumption */
+ pstate.finaltupchecked = false;
+ numArrayKeys = so->numArrayKeys;
+
minoff = P_FIRSTDATAKEY(opaque);
maxoff = PageGetMaxOffsetNumber(page);
@@ -1609,9 +1613,12 @@ _bt_readpage(IndexScanDesc scan, ScanDirection dir, OffsetNumber offnum)
* the last item on the page would give a more precise answer.
*
* We skip this for the first page in the scan to evade the possible
- * slowdown of the point queries.
+ * slowdown of point queries. Never apply the optimization with a scans
+ * that uses array keys, either, since that breaks certain assumptions.
+ * (Our search-type scan keys change whenever _bt_checkkeys advances the
+ * arrays, invalidating any precheck. Tracking all that would be tricky.)
*/
- if (!so->firstPage && minoff < maxoff)
+ if (!so->firstPage && !numArrayKeys && minoff < maxoff)
{
ItemId iid;
IndexTuple itup;
@@ -1625,8 +1632,9 @@ _bt_readpage(IndexScanDesc scan, ScanDirection dir, OffsetNumber offnum)
* set flag to true if all required keys are satisfied and false
* otherwise.
*/
- (void) _bt_checkkeys(scan, itup, indnatts, dir,
- &requiredMatchedByPrecheck, false);
+ _bt_checkkeys(scan, &pstate, itup, false, false);
+ requiredMatchedByPrecheck = pstate.continuescan;
+ pstate.continuescan = true; /* reset */
}
else
{
@@ -1636,6 +1644,14 @@ _bt_readpage(IndexScanDesc scan, ScanDirection dir, OffsetNumber offnum)
if (ScanDirectionIsForward(dir))
{
+ /* SK_SEARCHARRAY forward scans must provide high key up front */
+ if (numArrayKeys && !P_RIGHTMOST(opaque))
+ {
+ ItemId iid = PageGetItemId(page, P_HIKEY);
+
+ pstate.finaltup = (IndexTuple) PageGetItem(page, iid);
+ }
+
/* load items[] in ascending order */
itemIndex = 0;
@@ -1659,8 +1675,8 @@ _bt_readpage(IndexScanDesc scan, ScanDirection dir, OffsetNumber offnum)
itup = (IndexTuple) PageGetItem(page, iid);
- passes_quals = _bt_checkkeys(scan, itup, indnatts, dir,
- &continuescan, requiredMatchedByPrecheck);
+ passes_quals = _bt_checkkeys(scan, &pstate, itup, false,
+ requiredMatchedByPrecheck);
/*
* If the result of prechecking required keys was true, then in
@@ -1668,8 +1684,8 @@ _bt_readpage(IndexScanDesc scan, ScanDirection dir, OffsetNumber offnum)
* result is the same.
*/
Assert(!requiredMatchedByPrecheck ||
- passes_quals == _bt_checkkeys(scan, itup, indnatts, dir,
- &continuescan, false));
+ passes_quals == _bt_checkkeys(scan, &pstate, itup, false,
+ false));
if (passes_quals)
{
/* tuple passes all scan key conditions */
@@ -1703,7 +1719,7 @@ _bt_readpage(IndexScanDesc scan, ScanDirection dir, OffsetNumber offnum)
}
}
/* When !continuescan, there can't be any more matches, so stop */
- if (!continuescan)
+ if (!pstate.continuescan)
break;
offnum = OffsetNumberNext(offnum);
@@ -1720,17 +1736,16 @@ _bt_readpage(IndexScanDesc scan, ScanDirection dir, OffsetNumber offnum)
* only appear on non-pivot tuples on the right sibling page are
* common.
*/
- if (continuescan && !P_RIGHTMOST(opaque))
+ if (pstate.continuescan && !P_RIGHTMOST(opaque))
{
ItemId iid = PageGetItemId(page, P_HIKEY);
- IndexTuple itup = (IndexTuple) PageGetItem(page, iid);
- int truncatt;
+ IndexTuple itup;
- truncatt = BTreeTupleGetNAtts(itup, scan->indexRelation);
- _bt_checkkeys(scan, itup, truncatt, dir, &continuescan, false);
+ itup = (IndexTuple) PageGetItem(page, iid);
+ _bt_checkkeys(scan, &pstate, itup, true, false);
}
- if (!continuescan)
+ if (!pstate.continuescan)
so->currPos.moreRight = false;
Assert(itemIndex <= MaxTIDsPerBTreePage);
@@ -1740,6 +1755,14 @@ _bt_readpage(IndexScanDesc scan, ScanDirection dir, OffsetNumber offnum)
}
else
{
+ /* SK_SEARCHARRAY backward scans must provide final tuple up front */
+ if (numArrayKeys && minoff <= maxoff)
+ {
+ ItemId iid = PageGetItemId(page, minoff);
+
+ pstate.finaltup = (IndexTuple) PageGetItem(page, iid);
+ }
+
/* load items[] in descending order */
itemIndex = MaxTIDsPerBTreePage;
@@ -1751,6 +1774,7 @@ _bt_readpage(IndexScanDesc scan, ScanDirection dir, OffsetNumber offnum)
IndexTuple itup;
bool tuple_alive;
bool passes_quals;
+ bool finaltup = (offnum == minoff);
/*
* If the scan specifies not to return killed tuples, then we
@@ -1761,12 +1785,18 @@ _bt_readpage(IndexScanDesc scan, ScanDirection dir, OffsetNumber offnum)
* tuple on the page, we do check the index keys, to prevent
* uselessly advancing to the page to the left. This is similar
* to the high key optimization used by forward scans.
+ *
+ * Separately, _bt_checkkeys actually requires that we call it
+ * with the final non-pivot tuple from the page, if there's one
+ * (final processed tuple, or first tuple in offset number terms).
+ * We must indicate which particular tuple comes last, too.
*/
if (scan->ignore_killed_tuples && ItemIdIsDead(iid))
{
Assert(offnum >= P_FIRSTDATAKEY(opaque));
- if (offnum > P_FIRSTDATAKEY(opaque))
+ if (!finaltup)
{
+ Assert(offnum > minoff);
offnum = OffsetNumberPrev(offnum);
continue;
}
@@ -1778,8 +1808,8 @@ _bt_readpage(IndexScanDesc scan, ScanDirection dir, OffsetNumber offnum)
itup = (IndexTuple) PageGetItem(page, iid);
- passes_quals = _bt_checkkeys(scan, itup, indnatts, dir,
- &continuescan, requiredMatchedByPrecheck);
+ passes_quals = _bt_checkkeys(scan, &pstate, itup, finaltup,
+ requiredMatchedByPrecheck);
/*
* If the result of prechecking required keys was true, then in
@@ -1787,8 +1817,8 @@ _bt_readpage(IndexScanDesc scan, ScanDirection dir, OffsetNumber offnum)
* result is the same.
*/
Assert(!requiredMatchedByPrecheck ||
- passes_quals == _bt_checkkeys(scan, itup, indnatts, dir,
- &continuescan, false));
+ passes_quals == _bt_checkkeys(scan, &pstate, itup,
+ finaltup, false));
if (passes_quals && tuple_alive)
{
/* tuple passes all scan key conditions */
@@ -1827,7 +1857,7 @@ _bt_readpage(IndexScanDesc scan, ScanDirection dir, OffsetNumber offnum)
}
}
}
- if (!continuescan)
+ if (!pstate.continuescan)
{
/* there can't be any more matches, so stop */
so->currPos.moreLeft = false;
diff --git a/src/backend/access/nbtree/nbtutils.c b/src/backend/access/nbtree/nbtutils.c
index 1510b97fb..4d8e33a4d 100644
--- a/src/backend/access/nbtree/nbtutils.c
+++ b/src/backend/access/nbtree/nbtutils.c
@@ -33,7 +33,7 @@
typedef struct BTSortArrayContext
{
- FmgrInfo flinfo;
+ FmgrInfo *orderproc;
Oid collation;
bool reverse;
} BTSortArrayContext;
@@ -41,15 +41,41 @@ typedef struct BTSortArrayContext
static Datum _bt_find_extreme_element(IndexScanDesc scan, ScanKey skey,
StrategyNumber strat,
Datum *elems, int nelems);
+static void _bt_sort_array_cmp_setup(IndexScanDesc scan, ScanKey skey);
static int _bt_sort_array_elements(IndexScanDesc scan, ScanKey skey,
bool reverse,
Datum *elems, int nelems);
+static int _bt_merge_arrays(IndexScanDesc scan, ScanKey skey, bool reverse,
+ Datum *elems_orig, int nelems_orig,
+ Datum *elems_next, int nelems_next);
static int _bt_compare_array_elements(const void *a, const void *b, void *arg);
+static inline int32 _bt_compare_array_skey(FmgrInfo *orderproc,
+ Datum tupdatum, bool tupnull,
+ Datum arrdatum, ScanKey cur);
+static int _bt_binsrch_array_skey(FmgrInfo *orderproc,
+ bool cur_elem_start, ScanDirection dir,
+ Datum tupdatum, bool tupnull,
+ BTArrayKeyInfo *array, ScanKey cur,
+ int32 *final_result);
+static bool _bt_advance_array_keys_increment(IndexScanDesc scan, ScanDirection dir);
+static bool _bt_tuple_before_array_skeys(IndexScanDesc scan,
+ BTReadPageState *pstate,
+ IndexTuple tuple, int sktrig);
+static bool _bt_advance_array_keys(IndexScanDesc scan, BTReadPageState *pstate,
+ IndexTuple tuple, int sktrig);
+static void _bt_update_keys_with_arraykeys(IndexScanDesc scan);
+#ifdef USE_ASSERT_CHECKING
+static bool _bt_verify_keys_with_arraykeys(IndexScanDesc scan);
+#endif
static bool _bt_compare_scankey_args(IndexScanDesc scan, ScanKey op,
ScanKey leftarg, ScanKey rightarg,
bool *result);
static bool _bt_fix_scankey_strategy(ScanKey skey, int16 *indoption);
static void _bt_mark_scankey_required(ScanKey skey);
+static bool _bt_check_compare(ScanDirection dir, BTScanOpaque so,
+ IndexTuple tuple, int tupnatts, TupleDesc tupdesc,
+ bool *continuescan, int *sktrig,
+ bool requiredMatchedByPrecheck);
static bool _bt_check_rowcompare(ScanKey skey,
IndexTuple tuple, int tupnatts, TupleDesc tupdesc,
ScanDirection dir, bool *continuescan);
@@ -198,13 +224,48 @@ _bt_freestack(BTStack stack)
* If there are any SK_SEARCHARRAY scan keys, deconstruct the array(s) and
* set up BTArrayKeyInfo info for each one that is an equality-type key.
* Prepare modified scan keys in so->arrayKeyData, which will hold the current
- * array elements during each primitive indexscan operation. For inequality
- * array keys, it's sufficient to find the extreme element value and replace
- * the whole array with that scalar value.
+ * array elements.
+ *
+ * _bt_preprocess_keys treats each primitive scan as an independent piece of
+ * work. That structure pushes the responsibility for preprocessing that must
+ * work "across array keys" onto us. This division of labor makes sense once
+ * you consider that we're typically called no more than once per btrescan,
+ * whereas _bt_preprocess_keys is always called once per primitive index scan.
+ *
+ * Currently we perform two kinds of preprocessing to deal with redundancies.
+ * For inequality array keys, it's sufficient to find the extreme element
+ * value and replace the whole array with that scalar value. This eliminates
+ * all but one array key as redundant. Similarly, we are capable of "merging
+ * together" multiple equality array keys from two or more input scan keys
+ * into a single output scan key that contains only the intersecting array
+ * elements. This can eliminate many redundant array elements, as well as
+ * eliminating whole array scan keys as redundant.
+ *
+ * Note: _bt_start_array_keys actually sets up the cur_elem counters later on,
+ * once the scan direction is known.
*
* Note: the reason we need so->arrayKeyData, rather than just scribbling
* on scan->keyData, is that callers are permitted to call btrescan without
* supplying a new set of scankey data.
+ *
+ * Note: _bt_preprocess_keys is responsible for creating the so->keyData scan
+ * keys used by _bt_checkkeys. Index scans that don't use equality array keys
+ * will have _bt_preprocess_keys treat scan->keyData as input and so->keyData
+ * as output. Scans that use equality array keys have _bt_preprocess_keys
+ * treat so->arrayKeyData (which is our output) as their input, while (as per
+ * usual) outputting so->keyData for _bt_checkkeys. This function adds an
+ * additional layer of indirection that allows _bt_preprocess_keys to more or
+ * less avoid dealing with SK_SEARCHARRAY as a special case.
+ *
+ * Note: _bt_update_keys_with_arraykeys works by updating already-processed
+ * output keys (so->keyData) in-place. It cannot eliminate redundant or
+ * contradictory scan keys. This necessitates having _bt_preprocess_keys
+ * understand that it is unsafe to eliminate "redundant" SK_SEARCHARRAY
+ * equality scan keys on the basis of what is actually just the current array
+ * key values -- it must conservatively assume that such a scan key might no
+ * longer be redundant after the next _bt_update_keys_with_arraykeys call.
+ * Ideally we'd be able to deal with that by eliminating a subset of truly
+ * redundant array keys up-front, but it doesn't seem worth the trouble.
*/
void
_bt_preprocess_array_keys(IndexScanDesc scan)
@@ -212,7 +273,9 @@ _bt_preprocess_array_keys(IndexScanDesc scan)
BTScanOpaque so = (BTScanOpaque) scan->opaque;
int numberOfKeys = scan->numberOfKeys;
int16 *indoption = scan->indexRelation->rd_indoption;
+ int16 nkeyatts = IndexRelationGetNumberOfKeyAttributes(scan->indexRelation);
int numArrayKeys;
+ int lastEqualityArrayAtt = -1;
ScanKey cur;
int i;
MemoryContext oldContext;
@@ -265,6 +328,7 @@ _bt_preprocess_array_keys(IndexScanDesc scan)
/* Allocate space for per-array data in the workspace context */
so->arrayKeys = (BTArrayKeyInfo *) palloc0(numArrayKeys * sizeof(BTArrayKeyInfo));
+ so->orderProcs = (FmgrInfo *) palloc0(nkeyatts * sizeof(FmgrInfo));
/* Now process each array key */
numArrayKeys = 0;
@@ -281,6 +345,16 @@ _bt_preprocess_array_keys(IndexScanDesc scan)
int j;
cur = &so->arrayKeyData[i];
+
+ /*
+ * Attributes with equality-type scan keys (including but not limited
+ * to array scan keys) will need a 3-way comparison function. Set
+ * that up now. (Avoids repeating work for the same attribute.)
+ */
+ if (cur->sk_strategy == BTEqualStrategyNumber &&
+ !OidIsValid(so->orderProcs[cur->sk_attno - 1].fn_oid))
+ _bt_sort_array_cmp_setup(scan, cur);
+
if (!(cur->sk_flags & SK_SEARCHARRAY))
continue;
@@ -357,6 +431,47 @@ _bt_preprocess_array_keys(IndexScanDesc scan)
(indoption[cur->sk_attno - 1] & INDOPTION_DESC) != 0,
elem_values, num_nonnulls);
+ /*
+ * If this scan key is semantically equivalent to a previous equality
+ * operator array scan key, merge the two arrays together to eliminate
+ * redundant non-intersecting elements (and redundant whole scan keys)
+ */
+ if (lastEqualityArrayAtt == cur->sk_attno)
+ {
+ BTArrayKeyInfo *prev = &so->arrayKeys[numArrayKeys - 1];
+
+ Assert(so->arrayKeyData[prev->scan_key].sk_func.fn_oid ==
+ cur->sk_func.fn_oid);
+ Assert(so->arrayKeyData[prev->scan_key].sk_subtype ==
+ cur->sk_subtype);
+
+ num_elems = _bt_merge_arrays(scan, cur,
+ (indoption[cur->sk_attno - 1] & INDOPTION_DESC) != 0,
+ prev->elem_values, prev->num_elems,
+ elem_values, num_elems);
+
+ pfree(elem_values);
+
+ /*
+ * If there are no intersecting elements left from merging this
+ * array into the previous array on the same attribute, the scan
+ * qual is unsatisfiable
+ */
+ if (num_elems == 0)
+ {
+ numArrayKeys = -1;
+ break;
+ }
+
+ /*
+ * Lower the number of elements from the previous array, and mark
+ * this scan key/array as redundant for every primitive index scan
+ */
+ prev->num_elems = num_elems;
+ cur->sk_flags |= SK_BT_RDDNARRAY;
+ continue;
+ }
+
/*
* And set up the BTArrayKeyInfo data.
*/
@@ -364,6 +479,7 @@ _bt_preprocess_array_keys(IndexScanDesc scan)
so->arrayKeys[numArrayKeys].num_elems = num_elems;
so->arrayKeys[numArrayKeys].elem_values = elem_values;
numArrayKeys++;
+ lastEqualityArrayAtt = cur->sk_attno;
}
so->numArrayKeys = numArrayKeys;
@@ -437,26 +553,28 @@ _bt_find_extreme_element(IndexScanDesc scan, ScanKey skey,
}
/*
- * _bt_sort_array_elements() -- sort and de-dup array elements
+ * _bt_sort_array_cmp_setup() -- Look up array comparison function
*
- * The array elements are sorted in-place, and the new number of elements
- * after duplicate removal is returned.
- *
- * scan and skey identify the index column, whose opfamily determines the
- * comparison semantics. If reverse is true, we sort in descending order.
+ * Sets so->orderProcs[] for scan key's attribute. This is used to sort and
+ * deduplicate the attribute's array (if any). It's also used during binary
+ * searches of the next array key matching index tuples just beyond the range
+ * of the scan's current set of array keys.
*/
-static int
-_bt_sort_array_elements(IndexScanDesc scan, ScanKey skey,
- bool reverse,
- Datum *elems, int nelems)
+static void
+_bt_sort_array_cmp_setup(IndexScanDesc scan, ScanKey skey)
{
+ BTScanOpaque so = (BTScanOpaque) scan->opaque;
Relation rel = scan->indexRelation;
Oid elemtype;
RegProcedure cmp_proc;
- BTSortArrayContext cxt;
+ FmgrInfo *orderproc = &so->orderProcs[skey->sk_attno - 1];
- if (nelems <= 1)
- return nelems; /* no work to do */
+ /*
+ * Should do this for all equality strategy scan keys only (including
+ * those without any array). See _bt_advance_array_keys for details of
+ * why we need an ORDER proc for non-array equality strategy scan keys.
+ */
+ Assert(skey->sk_strategy == BTEqualStrategyNumber);
/*
* Determine the nominal datatype of the array elements. We have to
@@ -471,12 +589,10 @@ _bt_sort_array_elements(IndexScanDesc scan, ScanKey skey,
* Look up the appropriate comparison function in the opfamily.
*
* Note: it's possible that this would fail, if the opfamily is
- * incomplete, but it seems quite unlikely that an opfamily would omit
- * non-cross-type support functions for any datatype that it supports at
- * all.
+ * incomplete.
*/
cmp_proc = get_opfamily_proc(rel->rd_opfamily[skey->sk_attno - 1],
- elemtype,
+ rel->rd_opcintype[skey->sk_attno - 1],
elemtype,
BTORDER_PROC);
if (!RegProcedureIsValid(cmp_proc))
@@ -484,8 +600,32 @@ _bt_sort_array_elements(IndexScanDesc scan, ScanKey skey,
BTORDER_PROC, elemtype, elemtype,
rel->rd_opfamily[skey->sk_attno - 1]);
+ /* Save in orderproc entry for attribute */
+ fmgr_info_cxt(cmp_proc, orderproc, so->arrayContext);
+}
+
+/*
+ * _bt_sort_array_elements() -- sort and de-dup array elements
+ *
+ * The array elements are sorted in-place, and the new number of elements
+ * after duplicate removal is returned.
+ *
+ * scan and skey identify the index column, whose opfamily determines the
+ * comparison semantics. If reverse is true, we sort in descending order.
+ */
+static int
+_bt_sort_array_elements(IndexScanDesc scan, ScanKey skey,
+ bool reverse,
+ Datum *elems, int nelems)
+{
+ BTScanOpaque so = (BTScanOpaque) scan->opaque;
+ BTSortArrayContext cxt;
+
+ if (nelems <= 1)
+ return nelems; /* no work to do */
+
/* Sort the array elements */
- fmgr_info(cmp_proc, &cxt.flinfo);
+ cxt.orderproc = &so->orderProcs[skey->sk_attno - 1];
cxt.collation = skey->sk_collation;
cxt.reverse = reverse;
qsort_arg(elems, nelems, sizeof(Datum),
@@ -496,6 +636,48 @@ _bt_sort_array_elements(IndexScanDesc scan, ScanKey skey,
_bt_compare_array_elements, &cxt);
}
+/*
+ * _bt_merge_arrays() -- merge together duplicate array keys
+ *
+ * Both scan keys have array elements that have already been sorted and
+ * deduplicated.
+ */
+static int
+_bt_merge_arrays(IndexScanDesc scan, ScanKey skey, bool reverse,
+ Datum *elems_orig, int nelems_orig,
+ Datum *elems_next, int nelems_next)
+{
+ BTScanOpaque so = (BTScanOpaque) scan->opaque;
+ BTSortArrayContext cxt;
+ Datum *merged = palloc(sizeof(Datum) * Min(nelems_orig, nelems_next));
+ int merged_nelems = 0;
+
+ /*
+ * Incrementally copy the original array into a temp buffer, skipping over
+ * any items that are missing from the "next" array
+ */
+ cxt.orderproc = &so->orderProcs[skey->sk_attno - 1];
+ cxt.collation = skey->sk_collation;
+ cxt.reverse = reverse;
+ for (int i = 0; i < nelems_orig; i++)
+ {
+ Datum *elem = elems_orig + i;
+
+ if (bsearch_arg(elem, elems_next, nelems_next, sizeof(Datum),
+ _bt_compare_array_elements, &cxt))
+ merged[merged_nelems++] = *elem;
+ }
+
+ /*
+ * Overwrite the original array with temp buffer so that we're only left
+ * with intersecting array elements
+ */
+ memcpy(elems_orig, merged, merged_nelems * sizeof(Datum));
+ pfree(merged);
+
+ return merged_nelems;
+}
+
/*
* qsort_arg comparator for sorting array elements
*/
@@ -507,7 +689,7 @@ _bt_compare_array_elements(const void *a, const void *b, void *arg)
BTSortArrayContext *cxt = (BTSortArrayContext *) arg;
int32 compare;
- compare = DatumGetInt32(FunctionCall2Coll(&cxt->flinfo,
+ compare = DatumGetInt32(FunctionCall2Coll(cxt->orderproc,
cxt->collation,
da, db));
if (cxt->reverse)
@@ -515,6 +697,158 @@ _bt_compare_array_elements(const void *a, const void *b, void *arg)
return compare;
}
+/*
+ * _bt_compare_array_skey() -- apply array comparison function
+ *
+ * Compares caller's tuple attribute value to a scan key/array element.
+ * Helper function used during binary searches of SK_SEARCHARRAY arrays.
+ *
+ * This routine returns:
+ * <0 if tupdatum < arrdatum;
+ * 0 if tupdatum == arrdatum;
+ * >0 if tupdatum > arrdatum.
+ *
+ * This is essentially the same interface as _bt_compare: both functions
+ * compare the value that they're searching for to a binary search pivot.
+ * However, unlike _bt_compare, this function's "tuple argument" comes first,
+ * while its "array/scankey argument" comes second.
+*/
+static inline int32
+_bt_compare_array_skey(FmgrInfo *orderproc,
+ Datum tupdatum, bool tupnull,
+ Datum arrdatum, ScanKey cur)
+{
+ int32 result = 0;
+
+ Assert(cur->sk_strategy == BTEqualStrategyNumber);
+
+ if (tupnull) /* NULL tupdatum */
+ {
+ if (cur->sk_flags & SK_ISNULL)
+ result = 0; /* NULL "=" NULL */
+ else if (cur->sk_flags & SK_BT_NULLS_FIRST)
+ result = -1; /* NULL "<" NOT_NULL */
+ else
+ result = 1; /* NULL ">" NOT_NULL */
+ }
+ else if (cur->sk_flags & SK_ISNULL) /* NOT_NULL tupdatum, NULL arrdatum */
+ {
+ if (cur->sk_flags & SK_BT_NULLS_FIRST)
+ result = 1; /* NOT_NULL ">" NULL */
+ else
+ result = -1; /* NOT_NULL "<" NULL */
+ }
+ else
+ {
+ /*
+ * Like _bt_compare, we need to be careful of cross-type comparisons,
+ * so the left value has to be the value that came from an index tuple
+ */
+ result = DatumGetInt32(FunctionCall2Coll(orderproc, cur->sk_collation,
+ tupdatum, arrdatum));
+
+ /*
+ * We flip the sign by following the obvious rule: flip whenever the
+ * column is a DESC column.
+ *
+ * _bt_compare does it the wrong way around (flip when *ASC*) in order
+ * to compensate for passing its orderproc arguments backwards. We
+ * don't need to play these games because we find it natural to pass
+ * tupdatum as the left value (and arrdatum as the right value).
+ */
+ if (cur->sk_flags & SK_BT_DESC)
+ INVERT_COMPARE_RESULT(result);
+ }
+
+ return result;
+}
+
+/*
+ * _bt_binsrch_array_skey() -- Binary search for next matching array key
+ *
+ * Returns an index to the first array element >= caller's tupdatum argument.
+ * This convention is more natural for forwards scan callers, but that can't
+ * really matter to backwards scan callers. Both callers require handling for
+ * the case where the match we return is < tupdatum, and symmetric handling
+ * for the case where our best match is > tupdatum.
+ *
+ * Also sets *final_result to whatever _bt_compare_array_skey returned when we
+ * compared the returned array element to caller's tupdatum argument. This
+ * helps caller to decide what to do next. Caller should only accept the
+ * element we locate as-is when it's an exact match (i.e. *final_result is 0).
+ *
+ * cur_elem_start indicates if the binary search should begin at the array's
+ * current element (or have the current element as an upper bound if it's a
+ * backward scan). This (and information about the scan's direction) allows
+ * searches against required scan key arrays to reuse earlier search bounds.
+ */
+static int
+_bt_binsrch_array_skey(FmgrInfo *orderproc,
+ bool cur_elem_start, ScanDirection dir,
+ Datum tupdatum, bool tupnull,
+ BTArrayKeyInfo *array, ScanKey cur,
+ int32 *final_result)
+{
+ int low_elem,
+ mid_elem,
+ high_elem,
+ result = 0;
+
+ Assert(cur->sk_flags & SK_SEARCHARRAY);
+ Assert(cur->sk_strategy == BTEqualStrategyNumber);
+
+ low_elem = 0;
+ mid_elem = -1;
+ high_elem = array->num_elems - 1;
+ if (cur_elem_start)
+ {
+ if (ScanDirectionIsForward(dir))
+ low_elem = array->cur_elem;
+ else
+ high_elem = array->cur_elem;
+ }
+
+ while (high_elem > low_elem)
+ {
+ Datum arrdatum;
+
+ mid_elem = low_elem + ((high_elem - low_elem) / 2);
+ arrdatum = array->elem_values[mid_elem];
+
+ result = _bt_compare_array_skey(orderproc, tupdatum, tupnull,
+ arrdatum, cur);
+
+ if (result == 0)
+ {
+ /*
+ * Each array was deduplicated during initial preprocessing, so
+ * it's safe to quit as soon as we see an equal array element.
+ * This often saves an extra comparison or two...
+ */
+ low_elem = mid_elem;
+ break;
+ }
+
+ if (result > 0)
+ low_elem = mid_elem + 1;
+ else
+ high_elem = mid_elem;
+ }
+
+ /*
+ * ...but our caller also cares about how its searched-for tuple datum
+ * compares to the array element we'll return. We must set *final_result
+ * with the result of that comparison specifically.
+ */
+ if (low_elem != mid_elem)
+ result = _bt_compare_array_skey(orderproc, tupdatum, tupnull,
+ array->elem_values[low_elem], cur);
+
+ *final_result = result;
+
+ return low_elem;
+}
+
/*
* _bt_start_array_keys() -- Initialize array keys at start of a scan
*
@@ -539,30 +873,35 @@ _bt_start_array_keys(IndexScanDesc scan, ScanDirection dir)
curArrayKey->cur_elem = 0;
skey->sk_argument = curArrayKey->elem_values[curArrayKey->cur_elem];
}
-
- so->arraysStarted = true;
}
/*
- * _bt_advance_array_keys() -- Advance to next set of array elements
+ * _bt_advance_array_keys_increment() -- Advance to next set of array elements
+ *
+ * Advances the array keys by a single increment in the current scan
+ * direction. When there are multiple array keys this can roll over from the
+ * lowest order array to higher order arrays.
*
* Returns true if there is another set of values to consider, false if not.
* On true result, the scankeys are initialized with the next set of values.
+ * On false result, the scankeys stay the same, and the array keys are not
+ * advanced (every array is still at its final element for scan direction).
*/
-bool
-_bt_advance_array_keys(IndexScanDesc scan, ScanDirection dir)
+static bool
+_bt_advance_array_keys_increment(IndexScanDesc scan, ScanDirection dir)
{
BTScanOpaque so = (BTScanOpaque) scan->opaque;
bool found = false;
- int i;
+
+ Assert(!so->needPrimScan);
/*
* We must advance the last array key most quickly, since it will
* correspond to the lowest-order index column among the available
- * qualifications. This is necessary to ensure correct ordering of output
- * when there are multiple array keys.
+ * qualifications. Rolling over like this is necessary to ensure correct
+ * ordering of output when there are multiple array keys.
*/
- for (i = so->numArrayKeys - 1; i >= 0; i--)
+ for (int i = so->numArrayKeys - 1; i >= 0; i--)
{
BTArrayKeyInfo *curArrayKey = &so->arrayKeys[i];
ScanKey skey = &so->arrayKeyData[curArrayKey->scan_key];
@@ -596,19 +935,31 @@ _bt_advance_array_keys(IndexScanDesc scan, ScanDirection dir)
break;
}
- /* advance parallel scan */
- if (scan->parallel_scan != NULL)
- _bt_parallel_advance_array_keys(scan);
+ if (found)
+ return true;
/*
- * When no new array keys were found, the scan is "past the end" of the
- * array keys. _bt_start_array_keys can still "restart" the array keys if
- * a rescan is required.
+ * Don't allow the entire set of array keys to roll over: restore the
+ * array keys to the state they were in before we were called.
+ *
+ * This ensures that the array keys only ratchet forward (or backwards in
+ * the case of backward scans). Our "so->arrayKeyData[]" scan keys should
+ * always match the current "so->keyData[]" search-type scan keys (except
+ * for a brief moment during array key advancement).
*/
- if (!found)
- so->arraysStarted = false;
+ for (int i = 0; i < so->numArrayKeys; i++)
+ {
+ BTArrayKeyInfo *rollarray = &so->arrayKeys[i];
+ ScanKey skey = &so->arrayKeyData[rollarray->scan_key];
- return found;
+ if (ScanDirectionIsBackward(dir))
+ rollarray->cur_elem = 0;
+ else
+ rollarray->cur_elem = rollarray->num_elems - 1;
+ skey->sk_argument = rollarray->elem_values[rollarray->cur_elem];
+ }
+
+ return false;
}
/*
@@ -661,20 +1012,845 @@ _bt_restore_array_keys(IndexScanDesc scan)
* If we changed any keys, we must redo _bt_preprocess_keys. That might
* sound like overkill, but in cases with multiple keys per index column
* it seems necessary to do the full set of pushups.
- *
- * Also do this whenever the scan's set of array keys "wrapped around" at
- * the end of the last primitive index scan. There won't have been a call
- * to _bt_preprocess_keys from some other place following wrap around, so
- * we do it for ourselves.
*/
- if (changed || !so->arraysStarted)
- {
+ if (changed)
_bt_preprocess_keys(scan);
- /* The mark should have been set on a consistent set of keys... */
- Assert(so->qual_ok);
- }
+
+ Assert(_bt_verify_keys_with_arraykeys(scan));
}
+/*
+ * _bt_tuple_before_array_skeys() -- _bt_checkkeys array helper function
+ *
+ * Routine to determine if a continuescan=false tuple (set that way by an
+ * initial call to _bt_check_compare) must advance the scan's array keys.
+ * Only call here when _bt_check_compare already set continuescan=false.
+ *
+ * Returns true when caller passes a tuple that is < the current set of array
+ * keys for the most significant non-equal column/scan key (or > for backwards
+ * scans). This means that it cannot possibly be time to advance the array
+ * keys just yet. _bt_checkkeys caller should suppress its _bt_check_compare
+ * call, and return -- the tuple is treated as not satisfying our indexquals.
+ *
+ * Returns false when caller's tuple is >= the current array keys (or <=, in
+ * the case of backwards scans). This means that it is now time for our
+ * caller to advance the array keys (unless caller broke the rules by not
+ * checking with _bt_check_compare before calling here).
+ *
+ * Note: advancing the array keys may be required when every attribute value
+ * from caller's tuple is equal to corresponding scan key/array datums. See
+ * _bt_advance_array_keys and its handling of inequalities for details.
+ *
+ * Note: caller passes _bt_check_compare-set sktrig value to indicate which
+ * scan key triggered the call. If this is for any scan key that isn't a
+ * required equality strategy scan key, calling here is a no-op, meaning that
+ * we'll invariably return false. We just accept whatever _bt_check_compare
+ * indicated about the scan when it involves a required inequality scan key.
+ * We never care about nonrequired scan keys, including equality strategy
+ * array scan keys (though _bt_check_compare can temporarily end the scan to
+ * advance their ararys in _bt_advance_array_keys, which we'll never prevent).
+ */
+static bool
+_bt_tuple_before_array_skeys(IndexScanDesc scan, BTReadPageState *pstate,
+ IndexTuple tuple, int sktrig)
+{
+ BTScanOpaque so = (BTScanOpaque) scan->opaque;
+ Relation rel = scan->indexRelation;
+ ScanDirection dir = pstate->dir;
+ TupleDesc itupdesc = RelationGetDescr(rel);
+ bool tuple_before_array_keys = false;
+ ScanKey cur;
+ int ntupatts = BTreeTupleGetNAtts(tuple, rel),
+ ikey;
+
+ Assert(so->numArrayKeys > 0);
+ Assert(so->numberOfKeys > 0);
+ Assert(!so->needPrimScan);
+
+ for (cur = so->keyData + sktrig, ikey = sktrig;
+ ikey < so->numberOfKeys;
+ cur++, ikey++)
+ {
+ int attnum = cur->sk_attno;
+ FmgrInfo *orderproc;
+ Datum tupdatum;
+ bool tupnull;
+ int32 result;
+
+ /*
+ * Unlike _bt_check_compare and _bt_advance_array_keys, we never deal
+ * with inequality strategy scan keys (even those marked required). We
+ * also don't deal with non-required equality keys -- even when they
+ * happen to have arrays that might need to be advanced.
+ *
+ * Note: cannot "break" here due to corner cases involving redundant
+ * scan keys that weren't eliminated within _bt_preprocess_keys.
+ */
+ if (cur->sk_strategy != BTEqualStrategyNumber ||
+ (cur->sk_flags & SK_BT_REQFWD) == 0)
+ continue;
+
+ /* Required equality scan keys always required in both directions */
+ Assert((cur->sk_flags & SK_BT_REQFWD) &&
+ (cur->sk_flags & SK_BT_REQBKWD));
+
+ if (attnum > ntupatts)
+ {
+ /*
+ * When we reach a high key's truncated attribute, assume that the
+ * tuple attribute's value is >= the scan's equality constraint
+ * scan keys, forcing another _bt_advance_array_keys call.
+ *
+ * You might wonder why we don't treat truncated attributes as
+ * having values < our equality constraints instead; we're not
+ * treating the truncated attributes as having -inf values here,
+ * which is how things are done in _bt_compare.
+ *
+ * We're often called during finaltup prechecks, where we help our
+ * caller to decide whether or not it should terminate the current
+ * primitive index scan. Our behavior here implements a policy of
+ * being slightly optimistic about what will be found on the next
+ * page when the current primitive scan continues onto that page.
+ * (This is also closest to what _bt_check_compare does.)
+ */
+ break;
+ }
+
+ tupdatum = index_getattr(tuple, attnum, itupdesc, &tupnull);
+
+ orderproc = &so->orderProcs[attnum - 1];
+ result = _bt_compare_array_skey(orderproc, tupdatum, tupnull,
+ cur->sk_argument, cur);
+
+ if (result != 0)
+ {
+ if (ScanDirectionIsForward(dir))
+ tuple_before_array_keys = result < 0;
+ else
+ tuple_before_array_keys = result > 0;
+
+ break;
+ }
+ }
+
+ return tuple_before_array_keys;
+}
+
+/*
+ * _bt_array_keys_remain() -- start scheduled primitive index scan?
+ *
+ * Returns true if _bt_checkkeys scheduled another primitive index scan, just
+ * as the last one ended. Otherwise returns false, indicating that the array
+ * keys are now fully exhausted.
+ *
+ * Only call here during scans with one or more equality type array scan keys.
+ */
+bool
+_bt_array_keys_remain(IndexScanDesc scan, ScanDirection dir)
+{
+ BTScanOpaque so = (BTScanOpaque) scan->opaque;
+
+ Assert(so->numArrayKeys);
+
+ /*
+ * Array keys are advanced within _bt_checkkeys when the scan reaches the
+ * leaf level (more precisely, they're advanced when the scan reaches the
+ * end of each distinct set of array elements). This process avoids
+ * repeat access to leaf pages (across multiple primitive index scans) by
+ * advancing the scan's array keys when it allows the primitive index scan
+ * to find nearby matching tuples (or when it eliminates ranges of array
+ * key space that can't possibly be satisfied by any index tuple).
+ *
+ * _bt_checkkeys sets a simple flag variable to schedule another primitive
+ * index scan. This tells us what to do. We cannot rely on _bt_first
+ * always reaching _bt_checkkeys, though. There are various cases where
+ * that won't happen. For example, if the index is completely empty, then
+ * _bt_first won't get as far as calling _bt_readpage/_bt_checkkeys.
+ *
+ * We also don't expect _bt_checkkeys to be reached when searching for a
+ * non-existent value that happens to be higher than any existing value in
+ * the index. No _bt_checkkeys are expected when _bt_readpage reads the
+ * rightmost page during such a scan -- even a _bt_checkkeys call against
+ * the high key won't happen. There is an analogous issue for backwards
+ * scans that search for a value lower than all existing index tuples.
+ *
+ * We don't actually require special handling for these cases -- we don't
+ * need to be explicitly instructed to _not_ perform another primitive
+ * index scan. This is correct for all of the cases we've listed so far,
+ * which all involve primitive index scans that access pages "near the
+ * boundaries of the key space" (the leftmost page, the rightmost page, or
+ * an imaginary empty leaf root page). If _bt_checkkeys cannot be reached
+ * by a primitive index scan for one set of array keys, it follows that it
+ * also won't be reached for any later set of array keys...
+ */
+ if (!so->qual_ok)
+ {
+ /*
+ * ...though there is one exception: _bt_first's _bt_preprocess_keys
+ * call can determine that the scan's input scan keys can never be
+ * satisfied. That might be true for one set of array keys, but not
+ * the next set.
+ *
+ * Handle this by advancing the array keys incrementally ourselves.
+ * When this succeeds, start another primitive index scan.
+ */
+ CHECK_FOR_INTERRUPTS();
+
+ Assert(!so->needPrimScan);
+ if (_bt_advance_array_keys_increment(scan, dir))
+ return true;
+
+ /* Array keys are now exhausted */
+ }
+
+ /*
+ * Has another primitive index scan been scheduled by _bt_checkkeys?
+ */
+ if (so->needPrimScan)
+ {
+ /* Yes -- tell caller to call _bt_first once again */
+ so->needPrimScan = false;
+ if (scan->parallel_scan != NULL)
+ _bt_parallel_next_primitive_scan(scan);
+
+ return true;
+ }
+
+ /*
+ * No more primitive index scans. Terminate the top-level scan.
+ */
+ if (scan->parallel_scan != NULL)
+ _bt_parallel_done(scan);
+
+ return false;
+}
+
+/*
+ * _bt_advance_array_keys() -- Advance array elements using a tuple
+ *
+ * Like _bt_check_compare, our return value indicates if tuple satisfied the
+ * qual (specifically our new qual). We also set pstate.continuescan=false
+ * for caller when the top-level index scan is over (when all required array
+ * keys are now exhausted). Otherwise, we'll set pstate.continuescan=true,
+ * indicating that top-level scan should proceed onto the next tuple. After
+ * we return, all further calls to _bt_check_compare will also use our new
+ * qual (a qual with newly advanced array key values, set here by us).
+ *
+ * _bt_tuple_before_array_skeys is responsible for determining if the current
+ * place in the scan is >= the current array keys. Calling here before that
+ * point will prematurely advance the array keys, leading to wrong query
+ * results. (Actually, the case where the top-level scan ends might not
+ * advance the array keys, since there may be no further keys in the current
+ * scan direction.)
+ *
+ * We're responsible for ensuring that caller's tuple is <= current/newly
+ * advanced required array keys once we return (this postcondition is also
+ * checked via another assertion). We try to find an exact match, but failing
+ * that we'll advance the array keys to whatever set of keys comes next in the
+ * key space (among the keys that we actually have). Required array keys only
+ * ever "ratchet forwards", progressing in lock step with the scan itself.
+ *
+ * (The invariants are the same for backwards scans, except that the operators
+ * are flipped: just replace the precondition's >= operator with a <=, and the
+ * postcondition's <= operator with with a >=. In other words, just swap the
+ * precondition with the postcondition.)
+ *
+ * Note that we deal with all required equality strategy scan keys here; it's
+ * not limited to array scan keys. They're equality constraints for our
+ * purposes, and so are handled as degenerate single element arrays here.
+ * Obviously, they can never really advance in the way that real arrays can,
+ * but they must still affect how we advance real array scan keys, just like
+ * any other equality constraint. We have to keep around a 3-way ORDER proc
+ * for these (just using the "=" operator won't do), since in general whether
+ * the tuple is < or > some non-array equality key might influence advancement
+ * of any of the scan's actual arrays. The top-level scan can only terminate
+ * after it has processed the key space covered by the product of each and
+ * every equality constraint, including both non-arrays and (required) arrays.
+ * (Also, _bt_tuple_before_array_skeys needs to know the difference so that it
+ * can correctly suppress _bt_check_compare setting continuescan=false.)
+ *
+ * Note also that we may sometimes need to advance the array keys when the
+ * existing array keys are already an exact match for every corresponding
+ * value from caller's tuple according to _bt_check_compare. This is how we
+ * deal with inequalities that are required in the current scan direction.
+ * They can advance the array keys here, even though they don't influence the
+ * initial positioning strategy within _bt_first.
+ */
+static bool
+_bt_advance_array_keys(IndexScanDesc scan, BTReadPageState *pstate,
+ IndexTuple tuple, int sktrig)
+{
+ BTScanOpaque so = (BTScanOpaque) scan->opaque;
+ Relation rel = scan->indexRelation;
+ ScanDirection dir = pstate->dir;
+ TupleDesc itupdesc = RelationGetDescr(rel);
+ ScanKey cur;
+ int ikey,
+ first_nonrequired_ikey PG_USED_FOR_ASSERTS_ONLY = -1,
+ arrayidx = 0,
+ ntupatts = BTreeTupleGetNAtts(tuple, rel);
+ bool arrays_advanced = false,
+ arrays_exhausted,
+ beyond_end_advance = false,
+ foundRequiredOppositeDirOnly = false,
+ all_eqtype_sk_equal = true,
+ all_required_eqtype_sk_equal PG_USED_FOR_ASSERTS_ONLY = true;
+
+ Assert(_bt_verify_keys_with_arraykeys(scan));
+
+ /*
+ * Try to advance array keys via a series of binary searches.
+ *
+ * Loop iterates through the current scankeys (so->keyData[], which were
+ * output by _bt_preprocess_keys earlier) and then sets input scan keys
+ * (so->arrayKeyData[] scan keys) to new array values.
+ */
+ for (cur = so->keyData, ikey = 0; ikey < so->numberOfKeys; cur++, ikey++)
+ {
+ BTArrayKeyInfo *array = NULL;
+ ScanKey skeyarray = NULL;
+ FmgrInfo *orderproc;
+ int attnum = cur->sk_attno;
+ Datum tupdatum;
+ bool requiredSameDir = false,
+ requiredOppositeDirOnly = false,
+ tupnull;
+ int32 result;
+ int set_elem = 0;
+
+ /*
+ * Set up ORDER 3-way comparison function and array state
+ */
+ orderproc = &so->orderProcs[attnum - 1];
+ if (cur->sk_flags & SK_SEARCHARRAY &&
+ cur->sk_strategy == BTEqualStrategyNumber)
+ {
+ Assert(arrayidx < so->numArrayKeys);
+ array = &so->arrayKeys[arrayidx++];
+ skeyarray = &so->arrayKeyData[array->scan_key];
+ Assert(skeyarray->sk_attno == attnum);
+ }
+
+ if (((cur->sk_flags & SK_BT_REQFWD) && ScanDirectionIsForward(dir)) ||
+ ((cur->sk_flags & SK_BT_REQBKWD) && ScanDirectionIsBackward(dir)))
+ requiredSameDir = true;
+ else if (((cur->sk_flags & SK_BT_REQFWD) && ScanDirectionIsBackward(dir)) ||
+ ((cur->sk_flags & SK_BT_REQBKWD) && ScanDirectionIsForward(dir)))
+ requiredOppositeDirOnly = true;
+
+ /*
+ * Remember first non-required array scan key offset (for assertions)
+ */
+ if (!requiredSameDir && array && first_nonrequired_ikey == -1)
+ first_nonrequired_ikey = ikey;
+
+ /*
+ * Optimization: Skip over known-satisfied scan keys
+ */
+ if (ikey < sktrig)
+ continue;
+
+ /*
+ * When we come across an inequality scan key that's required in the
+ * opposite direction only, and is positioned after an unsatisfied
+ * scan key that's required in the current scan direction, remember it
+ */
+ if (requiredOppositeDirOnly)
+ {
+ Assert(ikey > sktrig);
+ Assert(cur->sk_strategy != BTEqualStrategyNumber);
+ Assert(!foundRequiredOppositeDirOnly);
+
+ foundRequiredOppositeDirOnly = true;
+
+ continue;
+ }
+
+ /*
+ * Other than that, we're not interested in scan keys that aren't
+ * required in the current scan direction (unless they're non-required
+ * array equality scan keys, which still need to be advanced by us)
+ */
+ if (!requiredSameDir && !array)
+ continue;
+
+ /*
+ * Whenever a required scan key triggers array key advancement within
+ * _bt_check_compare, the corresponding tuple attribute's value is
+ * typically < the scan key value (or > in the backwards scan case).
+ *
+ * If this is a required equality strategy scan key, this is just an
+ * optimization; we know that _bt_tuple_before_array_skeys has already
+ * determined that this scan key places us ahead of caller's tuple.
+ * There's no need to compare it a second time below.
+ *
+ * If this is a required inequality strategy scan key, we _must_ rely
+ * on _bt_check_compare like this; it knows all the intricacies around
+ * evaluating inequality strategy scan keys (e.g., row comparisons).
+ * There is no simple mapping onto the opclass ORDER proc we can use.
+ * But once we know that we have an unsatisfied inequality, we can
+ * treat it in the same way as an unsatisfied equality at this point.
+ *
+ * The arrays advance correctly in both cases because both involve the
+ * scan reaching the end of the key space for some array key (or some
+ * distinct set of array keys). The only difference is that in the
+ * equality strategy case the end is "between array keys", while in
+ * the inequality strategy case the end is "within an array key".
+ * Either way, we just advance higher order arrays by one increment.
+ *
+ * See below for a full explanation of "beyond end" advancement.
+ */
+ if (ikey == sktrig && !array)
+ {
+ Assert(requiredSameDir);
+ Assert(!arrays_advanced);
+
+ beyond_end_advance = true;
+
+ continue;
+ }
+
+ /*
+ * Nothing for us to do with a required inequality strategy scan key
+ * that wasn't the one that _bt_check_compare stopped on
+ */
+ if (cur->sk_strategy != BTEqualStrategyNumber)
+ continue;
+
+ /*
+ * Here we perform steps for all array scan keys after a required
+ * array scan key whose binary search triggered "beyond end of array
+ * element" array advancement due to encountering a tuple attribute
+ * value > the closest matching array key (or < for backwards scans).
+ *
+ * See below for a full explanation of "beyond end" advancement.
+ *
+ * NB: We must do this for all arrays -- not just required arrays.
+ * Otherwise the incremental array advancement step won't "carry".
+ */
+ if (beyond_end_advance)
+ {
+ int final_elem_dir;
+
+ if (ScanDirectionIsBackward(dir) || !array)
+ final_elem_dir = 0;
+ else
+ final_elem_dir = array->num_elems - 1;
+
+ if (array && array->cur_elem != final_elem_dir)
+ {
+ array->cur_elem = final_elem_dir;
+ skeyarray->sk_argument = array->elem_values[final_elem_dir];
+ arrays_advanced = true;
+ }
+
+ continue;
+ }
+
+ /*
+ * Here we perform steps for any required scan keys after the first
+ * required scan key whose tuple attribute was < the closest matching
+ * array key when we dealt with it (or > for backwards scans).
+ *
+ * This earlier required array key already puts us ahead of caller's
+ * tuple in the key space (for the current scan direction). We must
+ * make sure that subsequent lower-order array keys do not put us too
+ * far ahead (ahead of tuples that have yet to be seen by our caller).
+ * For example, when a tuple "(a, b) = (42, 5)" advances the array
+ * keys on "a" from 40 to 45, we must also set "b" to whatever the
+ * first array element for "b" is. It would be wrong to allow "b" to
+ * be set based on the tuple value.
+ *
+ * Perform the same steps with truncated high key attributes. You can
+ * think of this as a "binary search" for the element closest to the
+ * value -inf. Again, the arrays must never get ahead of the scan.
+ */
+ if (!all_eqtype_sk_equal || attnum > ntupatts)
+ {
+ int first_elem_dir;
+
+ if (ScanDirectionIsForward(dir) || !array)
+ first_elem_dir = 0;
+ else
+ first_elem_dir = array->num_elems - 1;
+
+ if (array && array->cur_elem != first_elem_dir)
+ {
+ array->cur_elem = first_elem_dir;
+ skeyarray->sk_argument = array->elem_values[first_elem_dir];
+ arrays_advanced = true;
+ }
+
+ /*
+ * Truncated -inf value will always be assumed to satisfy any
+ * required equality scan keys according to _bt_check_compare.
+ * Unset all_eqtype_sk_equal to avoid _bt_check_compare recheck.
+ *
+ * Deliberately don't unset all_required_eqtype_sk_equal here to
+ * avoid spurious postcondition assertion failures. We must
+ * follow _bt_tuple_before_array_skeys's example by not treating
+ * truncated attributes as having the exact value -inf.
+ */
+ all_eqtype_sk_equal = false;
+
+ continue;
+ }
+
+ /*
+ * Search in scankey's array for the corresponding tuple attribute
+ * value from caller's tuple
+ */
+ tupdatum = index_getattr(tuple, attnum, itupdesc, &tupnull);
+
+ if (array)
+ {
+ bool ratchets = (requiredSameDir && !arrays_advanced);
+
+ /*
+ * Binary search for closest match that's available from the array
+ */
+ set_elem = _bt_binsrch_array_skey(orderproc, ratchets, dir,
+ tupdatum, tupnull, array, cur,
+ &result);
+
+ /*
+ * Required arrays only ever ratchet forwards (backwards).
+ *
+ * This condition makes it safe for binary searches to skip over
+ * array elements that the scan must already be ahead of by now.
+ * That is strictly an optimization. Our assertion verifies that
+ * the condition holds, which doesn't depend on the optimization.
+ */
+ Assert(!ratchets ||
+ ((ScanDirectionIsForward(dir) && set_elem >= array->cur_elem) ||
+ (ScanDirectionIsBackward(dir) && set_elem <= array->cur_elem)));
+ Assert(set_elem >= 0 && set_elem < array->num_elems);
+ }
+ else
+ {
+ Assert(requiredSameDir);
+
+ /*
+ * This is a required non-array equality strategy scan key, which
+ * we'll treat as a degenerate single value array.
+ *
+ * _bt_advance_array_keys_increment won't have an array for this
+ * scan key, but it can't matter. If you think about how real
+ * single value arrays roll over, you'll understand why this is.
+ */
+ result = _bt_compare_array_skey(orderproc, tupdatum, tupnull,
+ cur->sk_argument, cur);
+ }
+
+ /*
+ * Consider "beyond end of array element" array advancement.
+ *
+ * When the tuple attribute value is > the closest matching array key
+ * (or < in the backwards scan case), we need to ratchet this array
+ * forward (backward) by one increment, so that caller's tuple ends up
+ * being < final array value instead (or > final array value instead).
+ * See also: state machine postcondition assertions, below.
+ *
+ * This process has to work for all of the arrays, not just this one:
+ * it must "carry" to higher-order arrays when the set_elem that we
+ * just used for this array happens to have been the final element
+ * (for current scan direction). We can't just increment (decrement)
+ * set_elem itself and expect correct behavior -- at least not when
+ * there's more than one array to consider.
+ *
+ * Our approach is to set each subsequent/lower-order array to its
+ * final element. We'll then advance all array keys incrementally,
+ * just outside the loop. That way all earlier/higher order arrays
+ * (arrays _before_ this one) will advance as needed by rolling over.
+ *
+ * The array keys advance a little like the way that a mileage gauge
+ * advances. Imagine a mechanical display that rolls over from 999 to
+ * 000 every time we drive our car another 1,000 miles. Each decimal
+ * digit behaves a little like an array from the array state machine
+ * implemented by this function. (_bt_advance_array_keys_increment
+ * won't actually allow the most significant array to roll over, but
+ * that's just defensive.)
+ *
+ * Suppose we have 3 array keys a, b, and c. Each "digit"/array has
+ * 10 distinct elements that happen to match across each array: values
+ * 0 through to 9. Caller's tuple "(a, b, c) = (3, 7.9, 2)" might
+ * initially have its "b" array advanced up to the value 7 (because 7
+ * was matched by its binary search), and its "c" array advanced to 9.
+ * The final incremental advancement step (outside the loop) will then
+ * finish things off by "advancing" the array on "c" to 0, which then
+ * carries over to "b" (since "c" rolled over when it advanced). Once
+ * we're done we'll have "rounded up from 7.9 to 8" for the "b" array,
+ * without needing to directly alter its set_elem.
+ *
+ * The "a" array won't have advanced on this occasion, since the "b"
+ * array didn't roll over in turn. But it would given a tuple like
+ * "(a, b, c) = (3, 9.9, 4)". A tuple like "(a, b, c) = (9, 9.9, 8)"
+ * will eventually try (though fail) to roll over the array on "a".
+ * Failing to roll over everything like this exhausts all the arrays.
+ *
+ * Under this scheme required array keys only ever ratchet forwards
+ * (or backwards), and always do so to the maximum possible extent
+ * that we can know will be safe without seeing the scan's next tuple.
+ */
+ if (requiredSameDir &&
+ ((ScanDirectionIsForward(dir) && result > 0) ||
+ (ScanDirectionIsBackward(dir) && result < 0)))
+ beyond_end_advance = true;
+
+ /*
+ * Also track whether all relevant attributes from caller's tuple will
+ * be equal to the scan's array keys once we're done with it
+ */
+ if (result != 0)
+ {
+ all_eqtype_sk_equal = false;
+ if (requiredSameDir)
+ all_required_eqtype_sk_equal = false;
+ }
+
+ /*
+ * Optimization: If this call was triggered by a non-required array,
+ * and we know that tuple won't satisfy the qual, we give up right
+ * away. This often avoids advancing the array keys, which will save
+ * wasted cycles from calling _bt_update_keys_with_arraykeys below
+ * (plus it avoids needlessly unsetting pstate.finaltupchecked).
+ */
+ if (!all_eqtype_sk_equal && !requiredSameDir && sktrig == ikey)
+ {
+ Assert(!arrays_advanced);
+ Assert(!foundRequiredOppositeDirOnly);
+
+ break;
+ }
+
+ /* Advance array keys, even if set_elem isn't an exact match */
+ if (array && array->cur_elem != set_elem)
+ {
+ array->cur_elem = set_elem;
+ skeyarray->sk_argument = array->elem_values[set_elem];
+ arrays_advanced = true;
+ }
+ }
+
+ /*
+ * Consider if we need to advance the array keys incrementally to finish
+ * off "beyond end of array element" array advancement. This is the only
+ * way that the array keys can be exhausted.
+ */
+ arrays_exhausted = false;
+ if (beyond_end_advance)
+ {
+ /* Non-required scan keys never exhaust arrays/end top-level scan */
+ Assert(sktrig < first_nonrequired_ikey ||
+ first_nonrequired_ikey == -1);
+
+ if (!_bt_advance_array_keys_increment(scan, dir))
+ arrays_exhausted = true;
+ else
+ arrays_advanced = true;
+
+ /*
+ * The newly advanced array keys won't be equal anymore, so remember
+ * that in order to avoid a second _bt_check_compare call for tuple
+ */
+ all_eqtype_sk_equal = all_required_eqtype_sk_equal = false;
+ }
+
+ if (arrays_advanced)
+ {
+ /*
+ * We advanced the array keys. Finalize everything by performing an
+ * in-place update of the scan's search-type scan keys.
+ *
+ * If we missed this final step then any call to _bt_check_compare
+ * would use stale array keys until such time as _bt_preprocess_keys
+ * was once again called by _bt_first.
+ */
+ _bt_update_keys_with_arraykeys(scan);
+
+ /*
+ * If any required array keys were advanced, be prepared to recheck
+ * the final tuple against the new array keys (as an optimization)
+ */
+ pstate->finaltupchecked = false;
+ }
+
+ /*
+ * State machine postcondition assertions.
+ *
+ * Tuple must now be <= current/newly advanced required array keys. Same
+ * goes for other required equality type scan keys, which are "degenerate
+ * single value arrays" for our purposes. (As usual the rule is the same
+ * for backwards scans once the operators are flipped around.)
+ *
+ * We're stricter than that in cases where the tuple was already equal to
+ * the previous array keys when we were called: tuple must now be < the
+ * new array keys (or > the array keys). This is a consequence of another
+ * rule: we must always advance the array keys by at least one increment
+ * (unless _bt_advance_array_keys_increment found that we'd exhausted all
+ * arrays, ending the top-level index scan).
+ *
+ * Our caller decides when to start primitive index scans based in part on
+ * the current array keys. It always needs to see a precise array-wise
+ * picture of the scan's progress. If we were to advance the array keys
+ * by less than the exact maximum safe amount, our caller might then make
+ * a subtly wrong decision about when to end the ongoing primitive scan.
+ * (These assertions won't reliably detect every case where the array keys
+ * haven't advanced by the expected/maximum amount, but they come close.)
+ */
+ Assert(_bt_verify_keys_with_arraykeys(scan));
+ Assert(arrays_exhausted ||
+ (_bt_tuple_before_array_skeys(scan, pstate, tuple, 0) ==
+ !all_required_eqtype_sk_equal));
+
+ /*
+ * If the array keys are now exhausted, end the top-level index scan
+ */
+ Assert(!so->needPrimScan);
+ if (arrays_exhausted)
+ {
+ /* Caller's tuple can't match new qual */
+ pstate->continuescan = false;
+ return false;
+ }
+
+ /*
+ * The array keys aren't exhausted, so provisionally assume that the
+ * current primitive index scan will continue
+ */
+ pstate->continuescan = true;
+
+ /*
+ * Does caller's tuple now match the new qual? Call _bt_check_compare a
+ * second time to find out (unless it's already clear that it can't).
+ */
+ if (all_eqtype_sk_equal)
+ {
+ bool continuescan;
+ int insktrig;
+
+ Assert(arrays_advanced);
+
+ if (likely(_bt_check_compare(dir, so, tuple, ntupatts, itupdesc,
+ &continuescan, &insktrig, false)))
+ return true;
+
+ /*
+ * Handle inequalities marked required in the current scan direction.
+ *
+ * It's just about possible that our _bt_check_compare call indicates
+ * that the scan should be terminated due to an unsatisfied inequality
+ * that wasn't initially recognized as such by us. Handle this by
+ * calling ourselves recursively while indicating that the trigger is
+ * now the inequality that we missed first time around.
+ *
+ * Note: we only need to do this in cases where the initial call to
+ * _bt_check_compare (that led to calling here) gave up upon finding
+ * an unsatisfied required equality/array scan key before it could
+ * reach the inequality. The second _bt_check_compare call took place
+ * after the array keys were advanced (to array keys that definitely
+ * match the tuple), so it can't have been overlooked a second time.
+ *
+ * Note: this is useful because we won't have to wait until the next
+ * tuple to advance the array keys a second time (to values that'll
+ * put the scan ahead of this tuple). Handling this ourselves isn't
+ * truly required. But it avoids complicating our contract. The only
+ * alternative is to allow an awkward exception to the general rule
+ * (the rule about always advancing the arrays to the maximum possible
+ * extent that caller's tuple can safely allow).
+ */
+ if (!continuescan)
+ {
+ Assert(insktrig > sktrig);
+ Assert(insktrig < first_nonrequired_ikey ||
+ first_nonrequired_ikey == -1);
+ return _bt_advance_array_keys(scan, pstate, tuple, insktrig);
+ }
+ }
+
+ /*
+ * Handle inequalities marked required in the opposite scan direction.
+ *
+ * If we advanced the array keys (which is now certain except in the case
+ * where we only needed to deal with non-required arrays), it's possible
+ * that the scan is now at the start of "matching" tuples (at least by the
+ * definition used by _bt_tuple_before_array_skeys), but is nevertheless
+ * still many leaf pages before the position that _bt_first is capable of
+ * repositioning the scan to.
+ *
+ * This can happen when we have an inequality scan key required in the
+ * opposite direction only, that's less significant than the scan key that
+ * triggered array advancement during our initial _bt_check_compare call.
+ * If even finaltup doesn't satisfy this less significant inequality scan
+ * key once we temporarily flip the scan direction, that indicates that
+ * even finaltup is before the _bt_first-wise initial position for these
+ * newly advanced array keys.
+ */
+ if (foundRequiredOppositeDirOnly && pstate->finaltup &&
+ !_bt_tuple_before_array_skeys(scan, pstate, pstate->finaltup, 0))
+ {
+ int nfinaltupatts = BTreeTupleGetNAtts(pstate->finaltup, rel);
+ ScanDirection flipped = -dir;
+ bool continuescan;
+ int opsktrig;
+
+ Assert(arrays_advanced);
+
+ _bt_check_compare(flipped, so, pstate->finaltup, nfinaltupatts,
+ itupdesc, &continuescan, &opsktrig, false);
+
+ if (!continuescan && opsktrig > sktrig)
+ {
+ /*
+ * Continuing the ongoing primitive index scan as-is risks
+ * uselessly scanning a huge number of leaf pages from before the
+ * page that we'll quickly jump to by descending the index anew.
+ *
+ * Play it safe: start a new primitive index scan. _bt_first is
+ * guaranteed to at least move the scan to the next leaf page.
+ */
+ Assert(opsktrig < first_nonrequired_ikey ||
+ first_nonrequired_ikey == -1);
+ pstate->continuescan = false;
+ so->needPrimScan = true;
+
+ return false;
+ }
+
+ /*
+ * Caller's tuple might still be before the _bt_first-wise start of
+ * matches for the new array keys, but at least finaltup is at or
+ * ahead of that position. That's good enough; continue as-is.
+ */
+ }
+
+ /*
+ * Caller's tuple is < the newly advanced array keys (or > when this is a
+ * backwards scan).
+ *
+ * It's possible that later tuples will also turn out to have values that
+ * are still < the now-current array keys (or > the current array keys).
+ * Our caller will handle this by performing what amounts to a linear
+ * search of the page, implemented by calling _bt_check_compare and then
+ * _bt_tuple_before_array_skeys for each tuple. Our caller should locate
+ * the first tuple >= the array keys before long (or locate the first
+ * tuple <= the array keys before long).
+ *
+ * This approach has various advantages over a binary search of the page.
+ * We expect that our caller will either quickly discover the next tuple
+ * covered by the current array keys, or quickly discover that it needs
+ * another primitive index scan (using its finaltup precheck) instead.
+ * Either way, a binary search is unlikely to beat a simple linear search.
+ *
+ * It's also not clear that a binary search will be any faster when we
+ * really do have to search through hundreds of tuples beyond this one.
+ * Several binary searches (one per array advancement) might be required
+ * while reading through a single page. Our linear search is structured
+ * as one continuous search that just advances the arrays in passing, and
+ * that only needs a little extra logic to deal with inequality scan keys.
+ */
+ return false;
+}
/*
* _bt_preprocess_keys() -- Preprocess scan keys
@@ -749,6 +1925,19 @@ _bt_restore_array_keys(IndexScanDesc scan)
* Again, missing cross-type operators might cause us to fail to prove the
* quals contradictory when they really are, but the scan will work correctly.
*
+ * Index scans with array keys need to be able to advance each array's keys
+ * and make them the current search-type scan keys without calling here. They
+ * expect to be able to call _bt_update_keys_with_arraykeys instead. We need
+ * to be careful about that case when we determine redundancy; equality quals
+ * must not be eliminated as redundant on the basis of array input keys that
+ * might change before another call here can take place.
+ *
+ * Note, however, that the presence of an array scan key doesn't affect how we
+ * determine if index quals are contradictory. Contradictory qual scans move
+ * on to the next primitive index scan right away, by incrementing the scan's
+ * array keys once control reaches _bt_array_keys_remain. There won't be a
+ * call to _bt_update_keys_with_arraykeys, so there's nothing for us to break.
+ *
* Row comparison keys are currently also treated without any smarts:
* we just transfer them into the preprocessed array without any
* editorialization. We can treat them the same as an ordinary inequality
@@ -895,8 +2084,11 @@ _bt_preprocess_keys(IndexScanDesc scan)
so->qual_ok = false;
return;
}
- /* else discard the redundant non-equality key */
- xform[j] = NULL;
+ else if (!(eq->sk_flags & SK_SEARCHARRAY))
+ {
+ /* else discard the redundant non-equality key */
+ xform[j] = NULL;
+ }
}
/* else, cannot determine redundancy, keep both keys */
}
@@ -986,6 +2178,22 @@ _bt_preprocess_keys(IndexScanDesc scan)
continue;
}
+ /*
+ * Is this an array scan key that _bt_preprocess_array_keys merged
+ * with some earlier array key during its initial preprocessing pass?
+ */
+ if (cur->sk_flags & SK_BT_RDDNARRAY)
+ {
+ /*
+ * key is redundant for this primitive index scan (and will be
+ * redundant during all subsequent primitive index scans)
+ */
+ Assert(cur->sk_flags & SK_SEARCHARRAY);
+ Assert(j == (BTEqualStrategyNumber - 1));
+ Assert(so->numArrayKeys > 0);
+ continue;
+ }
+
/* have we seen one of these before? */
if (xform[j] == NULL)
{
@@ -999,7 +2207,26 @@ _bt_preprocess_keys(IndexScanDesc scan)
&test_result))
{
if (test_result)
- xform[j] = cur;
+ {
+ if (j == (BTEqualStrategyNumber - 1) &&
+ ((xform[j]->sk_flags & SK_SEARCHARRAY) ||
+ (cur->sk_flags & SK_SEARCHARRAY)))
+ {
+ /*
+ * Must never replace an = array operator ourselves,
+ * nor can we ever fail to remember an = array
+ * operator. _bt_update_keys_with_arraykeys expects
+ * this.
+ */
+ ScanKey outkey = &outkeys[new_numberOfKeys++];
+
+ memcpy(outkey, cur, sizeof(ScanKeyData));
+ if (numberOfEqualCols == attno - 1)
+ _bt_mark_scankey_required(outkey);
+ }
+ else
+ xform[j] = cur;
+ }
else if (j == (BTEqualStrategyNumber - 1))
{
/* key == a && key == b, but a != b */
@@ -1027,6 +2254,98 @@ _bt_preprocess_keys(IndexScanDesc scan)
so->numberOfKeys = new_numberOfKeys;
}
+/*
+ * _bt_update_keys_with_arraykeys() -- Finalize advancing array keys
+ *
+ * This function just transfers newly advanced array keys that were set in
+ * "so->arrayKeyData[]" over to corresponding "so->keyData[]" scan keys. This
+ * avoids the full set of push-ups that take place in _bt_preprocess_keys at
+ * the start of each new primitive index scan. In particular, it avoids doing
+ * anything that would be considered unsafe while holding a buffer lock.
+ *
+ * Note that _bt_preprocess_keys is aware of our special requirements when
+ * considering if quals are redundant. For full details see comments above
+ * _bt_preprocess_array_keys (and above _bt_preprocess_keys itself).
+ */
+static void
+_bt_update_keys_with_arraykeys(IndexScanDesc scan)
+{
+ BTScanOpaque so = (BTScanOpaque) scan->opaque;
+ ScanKey cur;
+ int ikey,
+ arrayidx = 0;
+
+ Assert(so->qual_ok);
+
+ for (cur = so->keyData, ikey = 0; ikey < so->numberOfKeys; cur++, ikey++)
+ {
+ BTArrayKeyInfo *array;
+ ScanKey skeyarray;
+
+ Assert((cur->sk_flags & SK_BT_RDDNARRAY) == 0);
+
+ /* Just update equality array scan keys */
+ if (cur->sk_strategy != BTEqualStrategyNumber ||
+ !(cur->sk_flags & SK_SEARCHARRAY))
+ continue;
+
+ array = &so->arrayKeys[arrayidx++];
+ skeyarray = &so->arrayKeyData[array->scan_key];
+
+ /* Update the scan key's argument */
+ Assert(cur->sk_attno == skeyarray->sk_attno);
+ cur->sk_argument = skeyarray->sk_argument;
+ }
+
+ Assert(arrayidx == so->numArrayKeys);
+}
+
+/*
+ * Verify that the scan's "so->arrayKeyData[]" scan keys are in agreement with
+ * the current "so->keyData[]" search-type scan keys. Used within assertions.
+ */
+#ifdef USE_ASSERT_CHECKING
+static bool
+_bt_verify_keys_with_arraykeys(IndexScanDesc scan)
+{
+ BTScanOpaque so = (BTScanOpaque) scan->opaque;
+ ScanKey cur;
+ int ikey,
+ arrayidx = 0;
+
+ if (!so->qual_ok)
+ return false;
+
+ for (cur = so->keyData, ikey = 0; ikey < so->numberOfKeys; cur++, ikey++)
+ {
+ BTArrayKeyInfo *array;
+ ScanKey skeyarray;
+
+ if (cur->sk_strategy != BTEqualStrategyNumber ||
+ !(cur->sk_flags & SK_SEARCHARRAY))
+ continue;
+
+ array = &so->arrayKeys[arrayidx++];
+ skeyarray = &so->arrayKeyData[array->scan_key];
+
+ /* Verify so->arrayKeyData[] input key has expected sk_argument */
+ if (skeyarray->sk_argument != array->elem_values[array->cur_elem])
+ return false;
+
+ /* Verify so->arrayKeyData[] input key agrees with output key */
+ if (cur->sk_attno != skeyarray->sk_attno)
+ return false;
+ if (cur->sk_argument != skeyarray->sk_argument)
+ return false;
+ }
+
+ if (arrayidx != so->numArrayKeys)
+ return false;
+
+ return true;
+}
+#endif
+
/*
* Compare two scankey values using a specified operator.
*
@@ -1360,58 +2679,267 @@ _bt_mark_scankey_required(ScanKey skey)
*
* Return true if so, false if not. If the tuple fails to pass the qual,
* we also determine whether there's any need to continue the scan beyond
- * this tuple, and set *continuescan accordingly. See comments for
+ * this tuple, and set pstate.continuescan accordingly. See comments for
* _bt_preprocess_keys(), above, about how this is done.
*
- * Forward scan callers can pass a high key tuple in the hopes of having
- * us set *continuescan to false, and avoiding an unnecessary visit to
- * the page to the right.
+ * Forward scan callers can pass a high key tuple in the hopes of having us
+ * set pstate.continuescan to false, and avoiding an unnecessary visit to the
+ * page to the right.
+ *
+ * Forwards scan callers with equality type array scan keys are obligated to
+ * set up page state in a way that makes it possible for us to check the final
+ * tuple (the high key for a forward scan) early, before we've expended too
+ * much effort on comparing tuples that cannot possibly be matches for any set
+ * of array keys. This is just an optimization.
+ *
+ * Advances the current set of array keys for SK_SEARCHARRAY scans where
+ * appropriate. These callers are required to initialize the page level high
+ * key in pstate before the first call here for the page (when the scan
+ * direction is forwards). Note that we rely on _bt_readpage calling here in
+ * page offset number order (for its scan direction). Any other order will
+ * lead to inconsistent array key state.
*
* scan: index scan descriptor (containing a search-type scankey)
+ * pstate: Page level input and output parameters
* tuple: index tuple to test
- * tupnatts: number of attributes in tupnatts (high key may be truncated)
- * dir: direction we are scanning in
- * continuescan: output parameter (will be set correctly in all cases)
+ * finaltup: Is tuple the final one we'll be called with for this page?
* requiredMatchedByPrecheck: indicates that scan keys required for
* direction scan are already matched
*/
bool
-_bt_checkkeys(IndexScanDesc scan, IndexTuple tuple, int tupnatts,
- ScanDirection dir, bool *continuescan,
+_bt_checkkeys(IndexScanDesc scan, BTReadPageState *pstate,
+ IndexTuple tuple, bool finaltup,
bool requiredMatchedByPrecheck)
{
- TupleDesc tupdesc;
- BTScanOpaque so;
- int keysz;
+ TupleDesc tupdesc = RelationGetDescr(scan->indexRelation);
+ int natts = BTreeTupleGetNAtts(tuple, scan->indexRelation);
+ BTScanOpaque so = (BTScanOpaque) scan->opaque;
+ bool res;
+ int sktrig;
+
+ Assert(pstate->continuescan);
+ Assert(!so->needPrimScan);
+
+ res = _bt_check_compare(pstate->dir, so, tuple, natts, tupdesc,
+ &pstate->continuescan, &sktrig,
+ requiredMatchedByPrecheck);
+
+ /*
+ * Only one _bt_check_compare call is required in the common case where
+ * there are no equality-type array scan keys. Otherwise we can only
+ * accept _bt_check_compare's answer unreservedly when it didn't set
+ * continuescan=false.
+ */
+ if (!so->numArrayKeys || pstate->continuescan)
+ return res;
+
+ /*
+ * _bt_check_compare call set continuescan=false in the presence of
+ * equality type array keys.
+ *
+ * While we might really need to end the top-level index scan, most of the
+ * time this just means that the scan needs to reconsider its array keys.
+ */
+ if (_bt_tuple_before_array_skeys(scan, pstate, tuple, sktrig))
+ {
+ /*
+ * Current tuple is < the current array scan keys/equality constraints
+ * (or > in the backward scan case). Don't need to advance the array
+ * keys. Must decide whether to start a new primitive scan instead.
+ *
+ * If this tuple isn't the finaltup for the page, then recheck the
+ * finaltup stashed in pstate as an optimization. That allows us to
+ * quit scanning this page early when it's clearly hopeless (we don't
+ * need to wait for the finaltup call to give up on a primitive scan).
+ */
+ if (finaltup || (!pstate->finaltupchecked && pstate->finaltup &&
+ _bt_tuple_before_array_skeys(scan, pstate,
+ pstate->finaltup, 0)))
+ {
+ /*
+ * Give up on the ongoing primitive index scan.
+ *
+ * Even the final tuple (the high key for forward scans, or the
+ * tuple from page offset number 1 for backward scans) is before
+ * the current array keys. That strongly suggests that continuing
+ * this primitive scan would be less efficient than starting anew.
+ *
+ * See also: finaltup remarks after the _bt_advance_array_keys
+ * call below, which fully explain our policy around how and when
+ * primitive index scans end.
+ */
+ pstate->continuescan = false;
+
+ /*
+ * Set up a new primitive index scan that will reposition the
+ * top-level scan to the first leaf page whose key space is
+ * covered by our array keys. The top-level scan will "skip" a
+ * part of the index that can only contain non-matching tuples.
+ *
+ * Note: the next primitive index scan is guaranteed to land on
+ * some later leaf page (ideally it won't be this page's sibling).
+ * It follows that the top-level scan can never access the same
+ * leaf page more than once (unless the scan changes direction or
+ * btrestrpos is called). btcostestimate relies on this.
+ */
+ so->needPrimScan = true;
+ }
+ else
+ {
+ /*
+ * Stick with the ongoing primitive index scan, for now (override
+ * _bt_check_compare's suggestion that we end the scan).
+ *
+ * Note: we will end up here again and again given a group of
+ * tuples > the previous array keys and < the now-current keys
+ * (though only after an initial finaltup precheck determined that
+ * this page definitely covers key space from both array keysets).
+ * In effect, we perform a linear search of the page's remaining
+ * unscanned tuples every time the arrays advance past the key
+ * space of the scan's then-current tuple.
+ */
+ pstate->continuescan = true;
+
+ /*
+ * Our finaltup precheck determined that it is >= the current keys
+ * (although the current tuple is still < the current array keys).
+ *
+ * Remember that fact in pstate now. This avoids wasting cycles
+ * on repeating the same precheck step (checking the same finaltup
+ * against the same array keys) during later calls here for later
+ * tuples from this same leaf page.
+ */
+ pstate->finaltupchecked = true;
+ }
+
+ /* In any case, this indextuple doesn't match the qual */
+ return false;
+ }
+
+ /*
+ * Caller's tuple is >= the current set of array keys and other equality
+ * constraint scan keys (or <= if this is a backwards scans). It's now
+ * clear that we _must_ advance any required array keys in lockstep with
+ * the scan (or at least notice that the required array keys have been
+ * exhausted, which will end the top-level scan).
+ *
+ * Note: we might even advance the arrays when all existing keys are
+ * already equal to the values from the tuple at this point. See comments
+ * about inequality-driven array advancement above _bt_advance_array_keys.
+ */
+ if (_bt_advance_array_keys(scan, pstate, tuple, sktrig))
+ {
+ /* Tuple (which didn't match the old qual) now matches the new qual */
+ Assert(pstate->continuescan);
+ return true;
+ }
+
+ /*
+ * At this point we've either advanced the array keys beyond the tuple, or
+ * exhausted all array keys (which will end the top-level index scan).
+ * Either way, this index tuple doesn't match the new qual.
+ *
+ * The array keys usually advance using a tuple from before finaltup
+ * (there can only be one finaltup per page, of course). In the common
+ * case where we just advanced the array keys during a !finaltup call, we
+ * can be sure that there'll be at least one more opportunity to check the
+ * new array keys against another tuple from this same page. Things are
+ * more complicated for finaltup calls that advance the array keys at a
+ * page boundary. They'll often advance the arrays to values > finaltup,
+ * leaving us with no reliable information about the physical proximity of
+ * the first leaf page where matches for the new keys are to be found.
+ *
+ * Our policy is to allow our caller to move on to the next sibling page
+ * in these cases. This is speculative, in a way: it's always possible
+ * that the array keys will have advanced well beyond the key space
+ * covered by the next sibling page. And if it turns out like that then
+ * our caller will incur a wasted leaf page access.
+ *
+ * In practice this policy wins significantly more often than it loses.
+ * The fact that the final tuple advanced the array keys is an encouraging
+ * signal -- especially during forwards scans, where our high key/pivot
+ * finaltup has values derived from the right sibling's firstright tuple.
+ * This issue is quite likely to come up whenever multiple array keys are
+ * used by forward scans. There is a decent chance that every finaltup
+ * from every page will have at least one truncated -inf attribute, which
+ * makes it impossible for finaltup array advancement to advance the lower
+ * order arrays to exactly matching array elements. Workloads like that
+ * would see poor performance from a policy that conditions going to the
+ * next sibling page on having an exactly-matching finaltup on this page.
+ *
+ * Cases where continuing the scan onto the next sibling page is a bad
+ * idea usually quit scanning the page before even reaching finaltup; just
+ * making it as far as finaltup is a useful cue in its own right. This is
+ * partly due to a promise that _bt_advance_array_keys makes: it always
+ * advances the scan's array keys to the maximum possible extent that is
+ * sure to be safe, given what is known about the scan when it is called
+ * (namely the scan's current tuple and its array keys, though _not_ the
+ * next tuple whose key space is covered by any of the scan's arrays).
+ * That factor limits array advancement using finaltup to cases where no
+ * earlier tuple could bump the array keys to key space beyond finaltup,
+ * despite being given every opportunity to do so by us (with some help
+ * from _bt_advance_array_keys).
+ *
+ * Chances are good that finaltup won't be all that different to earlier
+ * nearby tuples: it is unlikely to make the tuple-wise position that
+ * matching tuples start at jump forward by a great many tuples, either.
+ * In particular, it is unlikely to jump by more tuples than caller will
+ * find on the next leaf page. That's why it makes sense to allow the
+ * ongoing primitive index scan to at least continue to the next page.
+ */
+
+ /* In any case, tuple doesn't match the new qual, either */
+ return false;
+}
+
+/*
+ * Test whether an indextuple satisfies current scan condition.
+ *
+ * Return true if so, false if not. If not, also clear *continuescan if
+ * it's not possible for any future tuples in the current scan direction to
+ * pass the qual with the current set of array keys.
+ *
+ * This is a subroutine for _bt_checkkeys. It is written with the assumption
+ * that reaching the end of each distinct set of array keys terminates the
+ * ongoing primitive index scan. It is up to our caller (which has more high
+ * level context than us) to override that initial determination when it makes
+ * more sense to advance the array keys and continue with further tuples from
+ * the same leaf page.
+ */
+static bool
+_bt_check_compare(ScanDirection dir, BTScanOpaque so,
+ IndexTuple tuple, int tupnatts, TupleDesc tupdesc,
+ bool *continuescan, int *sktrig,
+ bool requiredMatchedByPrecheck)
+{
int ikey;
ScanKey key;
- Assert(BTreeTupleGetNAtts(tuple, scan->indexRelation) == tupnatts);
+ Assert(!so->numArrayKeys || !requiredMatchedByPrecheck);
*continuescan = true; /* default assumption */
+ *sktrig = 0; /* default assumption */
- tupdesc = RelationGetDescr(scan->indexRelation);
- so = (BTScanOpaque) scan->opaque;
- keysz = so->numberOfKeys;
-
- for (key = so->keyData, ikey = 0; ikey < keysz; key++, ikey++)
+ for (key = so->keyData, ikey = 0; ikey < so->numberOfKeys; key++, ikey++)
{
Datum datum;
bool isNull;
Datum test;
bool requiredSameDir = false,
- requiredOppositeDir = false;
+ requiredOppositeDirOnly = false;
/*
* Check if the key is required for ordered scan in the same or
- * opposite direction. Save as flag variables for future usage.
+ * opposite direction. Also set an offset to this scan key for caller
+ * in case it stops the scan (used by scans that have array keys).
*/
if (((key->sk_flags & SK_BT_REQFWD) && ScanDirectionIsForward(dir)) ||
((key->sk_flags & SK_BT_REQBKWD) && ScanDirectionIsBackward(dir)))
requiredSameDir = true;
else if (((key->sk_flags & SK_BT_REQFWD) && ScanDirectionIsBackward(dir)) ||
((key->sk_flags & SK_BT_REQBKWD) && ScanDirectionIsForward(dir)))
- requiredOppositeDir = true;
+ requiredOppositeDirOnly = true;
+ *sktrig = ikey;
/*
* Is the key required for scanning for either forward or backward
@@ -1419,7 +2947,7 @@ _bt_checkkeys(IndexScanDesc scan, IndexTuple tuple, int tupnatts,
* known to be matched, skip the check. Except for the row keys,
* where NULLs could be found in the middle of matching values.
*/
- if ((requiredSameDir || requiredOppositeDir) &&
+ if ((requiredSameDir || requiredOppositeDirOnly) &&
!(key->sk_flags & SK_ROW_HEADER) && requiredMatchedByPrecheck)
continue;
@@ -1522,11 +3050,28 @@ _bt_checkkeys(IndexScanDesc scan, IndexTuple tuple, int tupnatts,
/*
* Apply the key checking function. When the key is required for
- * opposite direction scan, it must be already satisfied by
- * _bt_first() except for the NULLs checking, which have already done
- * above.
+ * opposite-direction scans it must be an inequality satisfied by
+ * _bt_first(), barring NULLs, which we just checked a moment ago.
+ *
+ * (Also can't apply this optimization with scans that use arrays,
+ * since _bt_advance_array_keys() sometimes allows the scan to see a
+ * few tuples from before the would-be _bt_first() starting position
+ * for the scan's just-advanced array keys.)
+ *
+ * Even required equality quals (that can't use this optimization due
+ * to being required in both scan directions) rely on the assumption
+ * that _bt_first() will always use the quals for initial positioning
+ * purposes. We stop the scan as soon as any required equality qual
+ * fails, so it had better only happen at the end of equal tuples in
+ * the current scan direction (never at the start of equal tuples).
+ * See comments in _bt_first().
+ *
+ * (The required equality quals issue also has specific implications
+ * for scans that use arrays. They sometimes perform a linear search
+ * of remaining unscanned tuples, forcing the primitive index scan to
+ * continue until it locates tuples >= the scan's new array keys.)
*/
- if (!requiredOppositeDir)
+ if (!requiredOppositeDirOnly || so->numArrayKeys)
{
test = FunctionCall2Coll(&key->sk_func, key->sk_collation,
datum, key->sk_argument);
@@ -1544,15 +3089,25 @@ _bt_checkkeys(IndexScanDesc scan, IndexTuple tuple, int tupnatts,
* Tuple fails this qual. If it's a required qual for the current
* scan direction, then we can conclude no further tuples will
* pass, either.
- *
- * Note: because we stop the scan as soon as any required equality
- * qual fails, it is critical that equality quals be used for the
- * initial positioning in _bt_first() when they are available. See
- * comments in _bt_first().
*/
if (requiredSameDir)
*continuescan = false;
+ /*
+ * Always set continuescan=false for equality-type array keys that
+ * don't pass -- even for an array scan key not marked required.
+ *
+ * A non-required scan key (array or otherwise) can never actually
+ * terminate the scan. It's just convenient for callers to treat
+ * continuescan=false as a signal that it might be time to advance
+ * the array keys, independent of whether they're required or not.
+ * (Even setting continuescan=false with a required scan key won't
+ * usually end a scan that uses arrays.)
+ */
+ if ((key->sk_flags & SK_SEARCHARRAY) &&
+ key->sk_strategy == BTEqualStrategyNumber)
+ *continuescan = false;
+
/*
* In any case, this indextuple doesn't match the qual.
*/
@@ -1571,7 +3126,7 @@ _bt_checkkeys(IndexScanDesc scan, IndexTuple tuple, int tupnatts,
* it's not possible for any future tuples in the current scan direction
* to pass the qual.
*
- * This is a subroutine for _bt_checkkeys, which see for more info.
+ * This is a subroutine for _bt_checkkeys/_bt_check_compare.
*/
static bool
_bt_check_rowcompare(ScanKey skey, IndexTuple tuple, int tupnatts,
diff --git a/src/backend/optimizer/path/indxpath.c b/src/backend/optimizer/path/indxpath.c
index 03a5fbdc6..e37597c26 100644
--- a/src/backend/optimizer/path/indxpath.c
+++ b/src/backend/optimizer/path/indxpath.c
@@ -106,8 +106,7 @@ static List *build_index_paths(PlannerInfo *root, RelOptInfo *rel,
IndexOptInfo *index, IndexClauseSet *clauses,
bool useful_predicate,
ScanTypeControl scantype,
- bool *skip_nonnative_saop,
- bool *skip_lower_saop);
+ bool *skip_nonnative_saop);
static List *build_paths_for_OR(PlannerInfo *root, RelOptInfo *rel,
List *clauses, List *other_clauses);
static List *generate_bitmap_or_paths(PlannerInfo *root, RelOptInfo *rel,
@@ -706,8 +705,6 @@ eclass_already_used(EquivalenceClass *parent_ec, Relids oldrelids,
* index AM supports them natively, we should just include them in simple
* index paths. If not, we should exclude them while building simple index
* paths, and then make a separate attempt to include them in bitmap paths.
- * Furthermore, we should consider excluding lower-order ScalarArrayOpExpr
- * quals so as to create ordered paths.
*/
static void
get_index_paths(PlannerInfo *root, RelOptInfo *rel,
@@ -716,37 +713,17 @@ get_index_paths(PlannerInfo *root, RelOptInfo *rel,
{
List *indexpaths;
bool skip_nonnative_saop = false;
- bool skip_lower_saop = false;
ListCell *lc;
/*
* Build simple index paths using the clauses. Allow ScalarArrayOpExpr
- * clauses only if the index AM supports them natively, and skip any such
- * clauses for index columns after the first (so that we produce ordered
- * paths if possible).
+ * clauses only if the index AM supports them natively.
*/
indexpaths = build_index_paths(root, rel,
index, clauses,
index->predOK,
ST_ANYSCAN,
- &skip_nonnative_saop,
- &skip_lower_saop);
-
- /*
- * If we skipped any lower-order ScalarArrayOpExprs on an index with an AM
- * that supports them, then try again including those clauses. This will
- * produce paths with more selectivity but no ordering.
- */
- if (skip_lower_saop)
- {
- indexpaths = list_concat(indexpaths,
- build_index_paths(root, rel,
- index, clauses,
- index->predOK,
- ST_ANYSCAN,
- &skip_nonnative_saop,
- NULL));
- }
+ &skip_nonnative_saop);
/*
* Submit all the ones that can form plain IndexScan plans to add_path. (A
@@ -784,7 +761,6 @@ get_index_paths(PlannerInfo *root, RelOptInfo *rel,
index, clauses,
false,
ST_BITMAPSCAN,
- NULL,
NULL);
*bitindexpaths = list_concat(*bitindexpaths, indexpaths);
}
@@ -817,27 +793,19 @@ get_index_paths(PlannerInfo *root, RelOptInfo *rel,
* to true if we found any such clauses (caller must initialize the variable
* to false). If it's NULL, we do not ignore ScalarArrayOpExpr clauses.
*
- * If skip_lower_saop is non-NULL, we ignore ScalarArrayOpExpr clauses for
- * non-first index columns, and we set *skip_lower_saop to true if we found
- * any such clauses (caller must initialize the variable to false). If it's
- * NULL, we do not ignore non-first ScalarArrayOpExpr clauses, but they will
- * result in considering the scan's output to be unordered.
- *
* 'rel' is the index's heap relation
* 'index' is the index for which we want to generate paths
* 'clauses' is the collection of indexable clauses (IndexClause nodes)
* 'useful_predicate' indicates whether the index has a useful predicate
* 'scantype' indicates whether we need plain or bitmap scan support
* 'skip_nonnative_saop' indicates whether to accept SAOP if index AM doesn't
- * 'skip_lower_saop' indicates whether to accept non-first-column SAOP
*/
static List *
build_index_paths(PlannerInfo *root, RelOptInfo *rel,
IndexOptInfo *index, IndexClauseSet *clauses,
bool useful_predicate,
ScanTypeControl scantype,
- bool *skip_nonnative_saop,
- bool *skip_lower_saop)
+ bool *skip_nonnative_saop)
{
List *result = NIL;
IndexPath *ipath;
@@ -848,7 +816,6 @@ build_index_paths(PlannerInfo *root, RelOptInfo *rel,
List *orderbyclausecols;
List *index_pathkeys;
List *useful_pathkeys;
- bool found_lower_saop_clause;
bool pathkeys_possibly_useful;
bool index_is_ordered;
bool index_only_scan;
@@ -880,19 +847,11 @@ build_index_paths(PlannerInfo *root, RelOptInfo *rel,
* on by btree and possibly other places.) The list can be empty, if the
* index AM allows that.
*
- * found_lower_saop_clause is set true if we accept a ScalarArrayOpExpr
- * index clause for a non-first index column. This prevents us from
- * assuming that the scan result is ordered. (Actually, the result is
- * still ordered if there are equality constraints for all earlier
- * columns, but it seems too expensive and non-modular for this code to be
- * aware of that refinement.)
- *
* We also build a Relids set showing which outer rels are required by the
* selected clauses. Any lateral_relids are included in that, but not
* otherwise accounted for.
*/
index_clauses = NIL;
- found_lower_saop_clause = false;
outer_relids = bms_copy(rel->lateral_relids);
for (indexcol = 0; indexcol < index->nkeycolumns; indexcol++)
{
@@ -903,30 +862,20 @@ build_index_paths(PlannerInfo *root, RelOptInfo *rel,
IndexClause *iclause = (IndexClause *) lfirst(lc);
RestrictInfo *rinfo = iclause->rinfo;
- /* We might need to omit ScalarArrayOpExpr clauses */
- if (IsA(rinfo->clause, ScalarArrayOpExpr))
+ /*
+ * We might need to omit ScalarArrayOpExpr clauses when index AM
+ * lacks native support
+ */
+ if (!index->amsearcharray && IsA(rinfo->clause, ScalarArrayOpExpr))
{
- if (!index->amsearcharray)
+ if (skip_nonnative_saop)
{
- if (skip_nonnative_saop)
- {
- /* Ignore because not supported by index */
- *skip_nonnative_saop = true;
- continue;
- }
- /* Caller had better intend this only for bitmap scan */
- Assert(scantype == ST_BITMAPSCAN);
- }
- if (indexcol > 0)
- {
- if (skip_lower_saop)
- {
- /* Caller doesn't want to lose index ordering */
- *skip_lower_saop = true;
- continue;
- }
- found_lower_saop_clause = true;
+ /* Ignore because not supported by index */
+ *skip_nonnative_saop = true;
+ continue;
}
+ /* Caller had better intend this only for bitmap scan */
+ Assert(scantype == ST_BITMAPSCAN);
}
/* OK to include this clause */
@@ -956,11 +905,9 @@ build_index_paths(PlannerInfo *root, RelOptInfo *rel,
/*
* 2. Compute pathkeys describing index's ordering, if any, then see how
* many of them are actually useful for this query. This is not relevant
- * if we are only trying to build bitmap indexscans, nor if we have to
- * assume the scan is unordered.
+ * if we are only trying to build bitmap indexscans.
*/
pathkeys_possibly_useful = (scantype != ST_BITMAPSCAN &&
- !found_lower_saop_clause &&
has_useful_pathkeys(root, rel));
index_is_ordered = (index->sortopfamily != NULL);
if (index_is_ordered && pathkeys_possibly_useful)
@@ -1212,7 +1159,6 @@ build_paths_for_OR(PlannerInfo *root, RelOptInfo *rel,
index, &clauseset,
useful_predicate,
ST_BITMAPSCAN,
- NULL,
NULL);
result = list_concat(result, indexpaths);
}
diff --git a/src/backend/utils/adt/selfuncs.c b/src/backend/utils/adt/selfuncs.c
index 35c9e3c86..2b622b7a5 100644
--- a/src/backend/utils/adt/selfuncs.c
+++ b/src/backend/utils/adt/selfuncs.c
@@ -6512,8 +6512,6 @@ genericcostestimate(PlannerInfo *root,
double numIndexTuples;
double spc_random_page_cost;
double num_sa_scans;
- double num_outer_scans;
- double num_scans;
double qual_op_cost;
double qual_arg_cost;
List *selectivityQuals;
@@ -6528,7 +6526,7 @@ genericcostestimate(PlannerInfo *root,
/*
* Check for ScalarArrayOpExpr index quals, and estimate the number of
- * index scans that will be performed.
+ * primitive index scans that will be performed for caller
*/
num_sa_scans = 1;
foreach(l, indexQuals)
@@ -6558,19 +6556,8 @@ genericcostestimate(PlannerInfo *root,
*/
numIndexTuples = costs->numIndexTuples;
if (numIndexTuples <= 0.0)
- {
numIndexTuples = indexSelectivity * index->rel->tuples;
- /*
- * The above calculation counts all the tuples visited across all
- * scans induced by ScalarArrayOpExpr nodes. We want to consider the
- * average per-indexscan number, so adjust. This is a handy place to
- * round to integer, too. (If caller supplied tuple estimate, it's
- * responsible for handling these considerations.)
- */
- numIndexTuples = rint(numIndexTuples / num_sa_scans);
- }
-
/*
* We can bound the number of tuples by the index size in any case. Also,
* always estimate at least one tuple is touched, even when
@@ -6608,27 +6595,31 @@ genericcostestimate(PlannerInfo *root,
*
* The above calculations are all per-index-scan. However, if we are in a
* nestloop inner scan, we can expect the scan to be repeated (with
- * different search keys) for each row of the outer relation. Likewise,
- * ScalarArrayOpExpr quals result in multiple index scans. This creates
- * the potential for cache effects to reduce the number of disk page
- * fetches needed. We want to estimate the average per-scan I/O cost in
- * the presence of caching.
+ * different search keys) for each row of the outer relation. This
+ * creates the potential for cache effects to reduce the number of disk
+ * page fetches needed. We want to estimate the average per-scan I/O cost
+ * in the presence of caching.
*
* We use the Mackert-Lohman formula (see costsize.c for details) to
* estimate the total number of page fetches that occur. While this
* wasn't what it was designed for, it seems a reasonable model anyway.
* Note that we are counting pages not tuples anymore, so we take N = T =
* index size, as if there were one "tuple" per page.
+ *
+ * Note: we assume that there will be no repeat index page fetches across
+ * ScalarArrayOpExpr primitive scans from the same logical index scan.
+ * This is guaranteed to be true for btree indexes, but is very optimistic
+ * with index AMs that cannot natively execute ScalarArrayOpExpr quals.
+ * However, these same index AMs also accept our default pessimistic
+ * approach to counting num_sa_scans (btree caller caps this), so we don't
+ * expect the final indexTotalCost to be wildly over-optimistic.
*/
- num_outer_scans = loop_count;
- num_scans = num_sa_scans * num_outer_scans;
-
- if (num_scans > 1)
+ if (loop_count > 1)
{
double pages_fetched;
/* total page fetches ignoring cache effects */
- pages_fetched = numIndexPages * num_scans;
+ pages_fetched = numIndexPages * loop_count;
/* use Mackert and Lohman formula to adjust for cache effects */
pages_fetched = index_pages_fetched(pages_fetched,
@@ -6638,11 +6629,9 @@ genericcostestimate(PlannerInfo *root,
/*
* Now compute the total disk access cost, and then report a pro-rated
- * share for each outer scan. (Don't pro-rate for ScalarArrayOpExpr,
- * since that's internal to the indexscan.)
+ * share for each outer scan
*/
- indexTotalCost = (pages_fetched * spc_random_page_cost)
- / num_outer_scans;
+ indexTotalCost = (pages_fetched * spc_random_page_cost) / loop_count;
}
else
{
@@ -6658,10 +6647,8 @@ genericcostestimate(PlannerInfo *root,
* evaluated once at the start of the scan to reduce them to runtime keys
* to pass to the index AM (see nodeIndexscan.c). We model the per-tuple
* CPU costs as cpu_index_tuple_cost plus one cpu_operator_cost per
- * indexqual operator. Because we have numIndexTuples as a per-scan
- * number, we have to multiply by num_sa_scans to get the correct result
- * for ScalarArrayOpExpr cases. Similarly add in costs for any index
- * ORDER BY expressions.
+ * indexqual operator. Similarly add in costs for any index ORDER BY
+ * expressions.
*
* Note: this neglects the possible costs of rechecking lossy operators.
* Detecting that that might be needed seems more expensive than it's
@@ -6674,7 +6661,7 @@ genericcostestimate(PlannerInfo *root,
indexStartupCost = qual_arg_cost;
indexTotalCost += qual_arg_cost;
- indexTotalCost += numIndexTuples * num_sa_scans * (cpu_index_tuple_cost + qual_op_cost);
+ indexTotalCost += numIndexTuples * (cpu_index_tuple_cost + qual_op_cost);
/*
* Generic assumption about index correlation: there isn't any.
@@ -6752,7 +6739,6 @@ btcostestimate(PlannerInfo *root, IndexPath *path, double loop_count,
bool eqQualHere;
bool found_saop;
bool found_is_null_op;
- double num_sa_scans;
ListCell *lc;
/*
@@ -6767,17 +6753,12 @@ btcostestimate(PlannerInfo *root, IndexPath *path, double loop_count,
*
* For a RowCompareExpr, we consider only the first column, just as
* rowcomparesel() does.
- *
- * If there's a ScalarArrayOpExpr in the quals, we'll actually perform N
- * index scans not one, but the ScalarArrayOpExpr's operator can be
- * considered to act the same as it normally does.
*/
indexBoundQuals = NIL;
indexcol = 0;
eqQualHere = false;
found_saop = false;
found_is_null_op = false;
- num_sa_scans = 1;
foreach(lc, path->indexclauses)
{
IndexClause *iclause = lfirst_node(IndexClause, lc);
@@ -6817,14 +6798,9 @@ btcostestimate(PlannerInfo *root, IndexPath *path, double loop_count,
else if (IsA(clause, ScalarArrayOpExpr))
{
ScalarArrayOpExpr *saop = (ScalarArrayOpExpr *) clause;
- Node *other_operand = (Node *) lsecond(saop->args);
- int alength = estimate_array_length(other_operand);
clause_op = saop->opno;
found_saop = true;
- /* count number of SA scans induced by indexBoundQuals only */
- if (alength > 1)
- num_sa_scans *= alength;
}
else if (IsA(clause, NullTest))
{
@@ -6884,13 +6860,6 @@ btcostestimate(PlannerInfo *root, IndexPath *path, double loop_count,
JOIN_INNER,
NULL);
numIndexTuples = btreeSelectivity * index->rel->tuples;
-
- /*
- * As in genericcostestimate(), we have to adjust for any
- * ScalarArrayOpExpr quals included in indexBoundQuals, and then round
- * to integer.
- */
- numIndexTuples = rint(numIndexTuples / num_sa_scans);
}
/*
@@ -6900,6 +6869,48 @@ btcostestimate(PlannerInfo *root, IndexPath *path, double loop_count,
genericcostestimate(root, path, loop_count, &costs);
+ /*
+ * Now compensate for btree's ability to efficiently execute scans with
+ * SAOP clauses.
+ *
+ * btree automatically combines individual ScalarArrayOpExpr primitive
+ * index scans whenever the tuples covered by the next set of array keys
+ * are close to tuples covered by the current set. This makes the final
+ * number of descents particularly difficult to estimate. However, btree
+ * scans never visit any single leaf page more than once. That puts a
+ * natural floor under the worst case number of descents.
+ *
+ * It's particularly important that we not wildly overestimate the number
+ * of descents needed for a clause list with several SAOPs -- the costs
+ * really aren't multiplicative in the way genericcostestimate expects. In
+ * general, most distinct combinations of SAOP keys will tend to not find
+ * any matching tuples. Furthermore, btree scans search for the next set
+ * of array keys using the next tuple in line, and so won't even need a
+ * direct comparison to eliminate most non-matching sets of array keys.
+ *
+ * Clamp the number of descents to the estimated number of leaf page
+ * visits. This is still fairly pessimistic, but tends to result in more
+ * accurate costing of scans with several SAOP clauses -- especially when
+ * each array has more than a few elements. The cost of adding additional
+ * array constants to a low-order SAOP column should saturate past a
+ * certain point (except where selectivity estimates continue to shift).
+ *
+ * Also clamp the number of descents to 1/3 the number of index pages.
+ * This avoids implausibly high estimates with low selectivity paths,
+ * where scans frequently require no more than one or two descents.
+ *
+ * XXX Ideally, we'd also account for the fact that non-boundary SAOP
+ * clause quals (which the B-Tree code uses "non-required" scan keys for)
+ * won't actually contribute to the total number of descents of the index.
+ * This would require pushing down more context into genericcostestimate.
+ */
+ if (costs.num_sa_scans > 1)
+ {
+ costs.num_sa_scans = Min(costs.num_sa_scans, costs.numIndexPages);
+ costs.num_sa_scans = Min(costs.num_sa_scans, index->pages / 3);
+ costs.num_sa_scans = Max(costs.num_sa_scans, 1);
+ }
+
/*
* Add a CPU-cost component to represent the costs of initial btree
* descent. We don't charge any I/O cost for touching upper btree levels,
@@ -6907,9 +6918,9 @@ btcostestimate(PlannerInfo *root, IndexPath *path, double loop_count,
* comparisons to descend a btree of N leaf tuples. We charge one
* cpu_operator_cost per comparison.
*
- * If there are ScalarArrayOpExprs, charge this once per SA scan. The
- * ones after the first one are not startup cost so far as the overall
- * plan is concerned, so add them only to "total" cost.
+ * If there are ScalarArrayOpExprs, charge this once per estimated
+ * primitive SA scan. The ones after the first one are not startup cost
+ * so far as the overall plan goes, so just add them to "total" cost.
*/
if (index->tuples > 1) /* avoid computing log(0) */
{
@@ -6926,7 +6937,8 @@ btcostestimate(PlannerInfo *root, IndexPath *path, double loop_count,
* in cases where only a single leaf page is expected to be visited. This
* cost is somewhat arbitrarily set at 50x cpu_operator_cost per page
* touched. The number of such pages is btree tree height plus one (ie,
- * we charge for the leaf page too). As above, charge once per SA scan.
+ * we charge for the leaf page too). As above, charge once per estimated
+ * primitive SA scan.
*/
descentCost = (index->tree_height + 1) * DEFAULT_PAGE_CPU_MULTIPLIER * cpu_operator_cost;
costs.indexStartupCost += descentCost;
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 42509042a..1515bbd40 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -4035,6 +4035,19 @@ description | Waiting for a newly initialized WAL file to reach durable storage
</para>
</note>
+ <note>
+ <para>
+ Every time an index is searched, the index's
+ <structname>pg_stat_all_indexes</structname>.<structfield>idx_scan</structfield>
+ field is incremented. This usually happens once per index scan node
+ execution, but might take place several times during execution of a scan
+ that searches for multiple values together. Only queries that use certain
+ <acronym>SQL</acronym> constructs to search for rows matching any value
+ out of a list (or an array) of multiple scalar values are affected. See
+ <xref linkend="functions-comparisons"/> for details.
+ </para>
+ </note>
+
</sect2>
<sect2 id="monitoring-pg-statio-all-tables-view">
diff --git a/src/test/regress/expected/create_index.out b/src/test/regress/expected/create_index.out
index acfd9d1f4..84c068ae3 100644
--- a/src/test/regress/expected/create_index.out
+++ b/src/test/regress/expected/create_index.out
@@ -1910,7 +1910,7 @@ SELECT count(*) FROM dupindexcols
(1 row)
--
--- Check ordering of =ANY indexqual results (bug in 9.2.0)
+-- Check that index scans with =ANY indexquals return rows in index order
--
explain (costs off)
SELECT unique1 FROM tenk1
@@ -1936,12 +1936,11 @@ explain (costs off)
SELECT thousand, tenthous FROM tenk1
WHERE thousand < 2 AND tenthous IN (1001,3000)
ORDER BY thousand;
- QUERY PLAN
--------------------------------------------------------
+ QUERY PLAN
+--------------------------------------------------------------------------------
Index Only Scan using tenk1_thous_tenthous on tenk1
- Index Cond: (thousand < 2)
- Filter: (tenthous = ANY ('{1001,3000}'::integer[]))
-(3 rows)
+ Index Cond: ((thousand < 2) AND (tenthous = ANY ('{1001,3000}'::integer[])))
+(2 rows)
SELECT thousand, tenthous FROM tenk1
WHERE thousand < 2 AND tenthous IN (1001,3000)
@@ -1952,18 +1951,35 @@ ORDER BY thousand;
1 | 1001
(2 rows)
+explain (costs off)
+SELECT thousand, tenthous FROM tenk1
+WHERE thousand < 2 AND tenthous IN (1001,3000)
+ORDER BY thousand DESC, tenthous DESC;
+ QUERY PLAN
+--------------------------------------------------------------------------------
+ Index Only Scan Backward using tenk1_thous_tenthous on tenk1
+ Index Cond: ((thousand < 2) AND (tenthous = ANY ('{1001,3000}'::integer[])))
+(2 rows)
+
+SELECT thousand, tenthous FROM tenk1
+WHERE thousand < 2 AND tenthous IN (1001,3000)
+ORDER BY thousand DESC, tenthous DESC;
+ thousand | tenthous
+----------+----------
+ 1 | 1001
+ 0 | 3000
+(2 rows)
+
SET enable_indexonlyscan = OFF;
explain (costs off)
SELECT thousand, tenthous FROM tenk1
WHERE thousand < 2 AND tenthous IN (1001,3000)
ORDER BY thousand;
- QUERY PLAN
---------------------------------------------------------------------------------------
- Sort
- Sort Key: thousand
- -> Index Scan using tenk1_thous_tenthous on tenk1
- Index Cond: ((thousand < 2) AND (tenthous = ANY ('{1001,3000}'::integer[])))
-(4 rows)
+ QUERY PLAN
+--------------------------------------------------------------------------------
+ Index Scan using tenk1_thous_tenthous on tenk1
+ Index Cond: ((thousand < 2) AND (tenthous = ANY ('{1001,3000}'::integer[])))
+(2 rows)
SELECT thousand, tenthous FROM tenk1
WHERE thousand < 2 AND tenthous IN (1001,3000)
@@ -1974,6 +1990,25 @@ ORDER BY thousand;
1 | 1001
(2 rows)
+explain (costs off)
+SELECT thousand, tenthous FROM tenk1
+WHERE thousand < 2 AND tenthous IN (1001,3000)
+ORDER BY thousand DESC, tenthous DESC;
+ QUERY PLAN
+--------------------------------------------------------------------------------
+ Index Scan Backward using tenk1_thous_tenthous on tenk1
+ Index Cond: ((thousand < 2) AND (tenthous = ANY ('{1001,3000}'::integer[])))
+(2 rows)
+
+SELECT thousand, tenthous FROM tenk1
+WHERE thousand < 2 AND tenthous IN (1001,3000)
+ORDER BY thousand DESC, tenthous DESC;
+ thousand | tenthous
+----------+----------
+ 1 | 1001
+ 0 | 3000
+(2 rows)
+
RESET enable_indexonlyscan;
--
-- Check elimination of constant-NULL subexpressions
diff --git a/src/test/regress/expected/join.out b/src/test/regress/expected/join.out
index 2c7327014..86e541780 100644
--- a/src/test/regress/expected/join.out
+++ b/src/test/regress/expected/join.out
@@ -8680,10 +8680,9 @@ where j1.id1 % 1000 = 1 and j2.id1 % 1000 = 1 and j2.id1 >= any (array[1,5]);
Merge Cond: (j1.id1 = j2.id1)
Join Filter: (j2.id2 = j1.id2)
-> Index Scan using j1_id1_idx on j1
- -> Index Only Scan using j2_pkey on j2
+ -> Index Scan using j2_id1_idx on j2
Index Cond: (id1 >= ANY ('{1,5}'::integer[]))
- Filter: ((id1 % 1000) = 1)
-(7 rows)
+(6 rows)
select * from j1
inner join j2 on j1.id1 = j2.id1 and j1.id2 = j2.id2
diff --git a/src/test/regress/sql/create_index.sql b/src/test/regress/sql/create_index.sql
index d49ce9f30..41b955a27 100644
--- a/src/test/regress/sql/create_index.sql
+++ b/src/test/regress/sql/create_index.sql
@@ -753,7 +753,7 @@ SELECT count(*) FROM dupindexcols
WHERE f1 BETWEEN 'WA' AND 'ZZZ' and id < 1000 and f1 ~<~ 'YX';
--
--- Check ordering of =ANY indexqual results (bug in 9.2.0)
+-- Check that index scans with =ANY indexquals return rows in index order
--
explain (costs off)
@@ -774,6 +774,15 @@ SELECT thousand, tenthous FROM tenk1
WHERE thousand < 2 AND tenthous IN (1001,3000)
ORDER BY thousand;
+explain (costs off)
+SELECT thousand, tenthous FROM tenk1
+WHERE thousand < 2 AND tenthous IN (1001,3000)
+ORDER BY thousand DESC, tenthous DESC;
+
+SELECT thousand, tenthous FROM tenk1
+WHERE thousand < 2 AND tenthous IN (1001,3000)
+ORDER BY thousand DESC, tenthous DESC;
+
SET enable_indexonlyscan = OFF;
explain (costs off)
@@ -785,6 +794,15 @@ SELECT thousand, tenthous FROM tenk1
WHERE thousand < 2 AND tenthous IN (1001,3000)
ORDER BY thousand;
+explain (costs off)
+SELECT thousand, tenthous FROM tenk1
+WHERE thousand < 2 AND tenthous IN (1001,3000)
+ORDER BY thousand DESC, tenthous DESC;
+
+SELECT thousand, tenthous FROM tenk1
+WHERE thousand < 2 AND tenthous IN (1001,3000)
+ORDER BY thousand DESC, tenthous DESC;
+
RESET enable_indexonlyscan;
--
--
2.42.0
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan
2023-11-07 12:20 Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan Matthias van de Meent <[email protected]>
2023-11-08 01:53 ` Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan Peter Geoghegan <[email protected]>
2023-11-11 21:08 ` Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan Matthias van de Meent <[email protected]>
2023-11-21 02:52 ` Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan Peter Geoghegan <[email protected]>
@ 2023-11-27 13:39 ` Heikki Linnakangas <[email protected]>
2023-12-05 03:25 ` Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan Peter Geoghegan <[email protected]>
2 siblings, 1 reply; 12+ messages in thread
From: Heikki Linnakangas @ 2023-11-27 13:39 UTC (permalink / raw)
To: Peter Geoghegan <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>; Tom Lane <[email protected]>; Tomas Vondra <[email protected]>; Jeff Davis <[email protected]>; benoit <[email protected]>; Alexander Korotkov <[email protected]>; Matthias van de Meent <[email protected]>
On 21/11/2023 04:52, Peter Geoghegan wrote:
> Attached is v7.
First, some high-level reactions before looking at the patch very closely:
- +1 on the general idea. Hard to see any downsides if implemented right.
- This changes the meaning of amsearcharray==true to mean that the
ordering is preserved with ScalarArrayOps, right? You change B-tree to
make that true, but what about any out-of-tree index AM extensions? I
don't know if any such extensions exist, and I don't think we should
jump through any hoops to preserve backwards compatibility here, but
probably deserves a notice in the release notes if nothing else.
- You use the term "primitive index scan" a lot, but it's not clear to
me what it means. Does one ScalarArrayOps turn into one "primitive index
scan"? Or each element in the array turns into a separate primitive
index scan? Or something in between? Maybe add a new section to the
README explain how that works.
- _bt_preprocess_array_keys() is called for each btrescan(). It performs
a lot of work like cmp function lookups and desconstructing and merging
the arrays, even if none of the SAOP keys change in the rescan. That
could make queries with nested loop joins like this slower than before:
"select * from generate_series(1, 50) g, tenk1 WHERE g = tenk1.unique1
and tenk1.two IN (1,2);".
- nbtutils.c is pretty large now. Perhaps create a new file
nbtpreprocesskeys.c or something?
- You and Matthias talked about an implicit state machine. I wonder if
this could be refactored to have a more explicit state machine. The
state transitions and interactions between _bt_checkkeys(),
_bt_advance_array_keys() and friends feel complicated.
And then some details:
> --- a/doc/src/sgml/monitoring.sgml
> +++ b/doc/src/sgml/monitoring.sgml
> @@ -4035,6 +4035,19 @@ description | Waiting for a newly initialized WAL file to reach durable storage
> </para>
> </note>
>
> + <note>
> + <para>
> + Every time an index is searched, the index's
> + <structname>pg_stat_all_indexes</structname>.<structfield>idx_scan</structfield>
> + field is incremented. This usually happens once per index scan node
> + execution, but might take place several times during execution of a scan
> + that searches for multiple values together. Only queries that use certain
> + <acronym>SQL</acronym> constructs to search for rows matching any value
> + out of a list (or an array) of multiple scalar values are affected. See
> + <xref linkend="functions-comparisons"/> for details.
> + </para>
> + </note>
> +
Is this true even without this patch? Maybe commit this separately.
The "Only queries ..." sentence feels difficult. Maybe something like
"For example, queries using IN (...) or = ANY(...) constructs.".
> * _bt_preprocess_keys treats each primitive scan as an independent piece of
> * work. That structure pushes the responsibility for preprocessing that must
> * work "across array keys" onto us. This division of labor makes sense once
> * you consider that we're typically called no more than once per btrescan,
> * whereas _bt_preprocess_keys is always called once per primitive index scan.
"That structure ..." is a garden-path sentence. I kept parsing "that
must work" as one unit, the same way as "that structure", and it didn't
make sense. Took me many re-reads to parse it correctly. Now that I get
it, it doesn't bother me anymore, but maybe it could be rephrased.
Is there _any_ situation where _bt_preprocess_array_keys() is called
more than once per btrescan?
> /*
> * Look up the appropriate comparison operator in the opfamily.
> *
> * Note: it's possible that this would fail, if the opfamily is
> * incomplete, but it seems quite unlikely that an opfamily would omit
> * non-cross-type comparison operators for any datatype that it supports
> * at all. ...
> */
I agree that's unlikely. I cannot come up with an example where you
would have cross-type operators between A and B, but no same-type
operators between B and B. For any real-world opfamily, that would be an
omission you'd probably want to fix.
Still I wonder if we could easily fall back if it doesn't exist? And
maybe add a check in the 'opr_sanity' test for that.
In _bt_readpage():
> /*
> * Prechecking the page with scan keys required for direction scan. We
> * check these keys with the last item on the page (according to our scan
> * direction). If these keys are matched, we can skip checking them with
> * every item on the page. Scan keys for our scan direction would
> * necessarily match the previous items. Scan keys required for opposite
> * direction scan are already matched by the _bt_first() call.
> *
> * With the forward scan, we do this check for the last item on the page
> * instead of the high key. It's relatively likely that the most
> * significant column in the high key will be different from the
> * corresponding value from the last item on the page. So checking with
> * the last item on the page would give a more precise answer.
> *
> * We skip this for the first page in the scan to evade the possible
> * slowdown of point queries. Never apply the optimization with a scans
> * that uses array keys, either, since that breaks certain assumptions.
> * (Our search-type scan keys change whenever _bt_checkkeys advances the
> * arrays, invalidating any precheck. Tracking all that would be tricky.)
> */
> if (!so->firstPage && !numArrayKeys && minoff < maxoff)
> {
It's sad to disable this optimization completely for array keys. It's
actually a regression from current master, isn't it? There's no
fundamental reason we couldn't do it for array keys so I think we should
do it.
_bt_checkkeys() is called in an assertion in _bt_readpage, but it has
the side-effect of advancing the array keys. Side-effects from an
assertion seems problematic.
Vague idea: refactor _bt_checkkeys() into something that doesn't have
side-effects, and have a separate function or an argument to
_bt_checkkeys() to advance to next array key. The prechecking
optimization and the Assertion could both use the side-effect-free function.
--
Heikki Linnakangas
Neon (https://neon.tech)
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan
2023-11-07 12:20 Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan Matthias van de Meent <[email protected]>
2023-11-08 01:53 ` Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan Peter Geoghegan <[email protected]>
2023-11-11 21:08 ` Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan Matthias van de Meent <[email protected]>
2023-11-21 02:52 ` Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan Peter Geoghegan <[email protected]>
2023-11-27 13:39 ` Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan Heikki Linnakangas <[email protected]>
@ 2023-12-05 03:25 ` Peter Geoghegan <[email protected]>
2023-12-05 05:01 ` Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan Peter Geoghegan <[email protected]>
0 siblings, 1 reply; 12+ messages in thread
From: Peter Geoghegan @ 2023-12-05 03:25 UTC (permalink / raw)
To: Heikki Linnakangas <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>; Tom Lane <[email protected]>; Tomas Vondra <[email protected]>; Jeff Davis <[email protected]>; benoit <[email protected]>; Alexander Korotkov <[email protected]>; Matthias van de Meent <[email protected]>
On Mon, Nov 27, 2023 at 5:39 AM Heikki Linnakangas <[email protected]> wrote:
> - +1 on the general idea. Hard to see any downsides if implemented right.
Glad you think so. The "no possible downside" perspective is one that
the planner sort of relies on, so this isn't just a nice-to-have -- it
might actually be a condition of committing the patch. It's important
that the planner can be very aggressive about using SAOP index quals,
without us suffering any real downside at execution time.
> - This changes the meaning of amsearcharray==true to mean that the
> ordering is preserved with ScalarArrayOps, right? You change B-tree to
> make that true, but what about any out-of-tree index AM extensions? I
> don't know if any such extensions exist, and I don't think we should
> jump through any hoops to preserve backwards compatibility here, but
> probably deserves a notice in the release notes if nothing else.
My interpretation is that the planner changes affect amcanorder +
amsearcharray index AMs, but have no impact on mere amsearcharray
index AMs. If anything this is a step *away* from knowing about nbtree
implementation details in the planner (though the planner's definition
of amcanorder is very close to the behavior from nbtree, down to
things like knowing all about nbtree strategy numbers). The planner
changes from the patch are all subtractive -- I'm removing kludges
that were added by bug fix commits. Things that weren't in the
original feature commit at all.
I used the term "my interpretation" here because it seems hard to
think of this in abstract terms, and to write a compatibility note for
this imaginary audience. I'm happy to go along with whatever you want,
though. Perhaps you can suggest a wording for this?
> - You use the term "primitive index scan" a lot, but it's not clear to
> me what it means. Does one ScalarArrayOps turn into one "primitive index
> scan"? Or each element in the array turns into a separate primitive
> index scan? Or something in between? Maybe add a new section to the
> README explain how that works.
The term primitive index scan refers to the thing that happens each
time _bt_first() is called -- with and without the patch. In other
words, it's what happens when pg_stat_all_indexes.idx_scan is
incremented.
You could argue that that's not quite the right thing to be focussing
on, with this new design. But it has precedent going for it. As I
said, it's the thing that pg_stat_all_indexes.idx_scan counts, which
is a pretty exact and tangible thing. So it's consistent with
historical practice, but also with what other index AMs do when
executing ScalarArrayOps non-natively.
> - _bt_preprocess_array_keys() is called for each btrescan(). It performs
> a lot of work like cmp function lookups and desconstructing and merging
> the arrays, even if none of the SAOP keys change in the rescan. That
> could make queries with nested loop joins like this slower than before:
> "select * from generate_series(1, 50) g, tenk1 WHERE g = tenk1.unique1
> and tenk1.two IN (1,2);".
But that's nothing new. _bt_preprocess_array_keys() isn't a new
function, and the way that it's called isn't new in any way.
That said, I certainly agree that we should be worried about any added
overhead in _bt_first for nested loop joins with an inner index scan.
In my experience that can be an important issue. I actually have a
TODO item about this already. It needs to be included in my work on
performance validation, on general principle.
> - nbtutils.c is pretty large now. Perhaps create a new file
> nbtpreprocesskeys.c or something?
Let me get back to you on this.
> - You and Matthias talked about an implicit state machine. I wonder if
> this could be refactored to have a more explicit state machine. The
> state transitions and interactions between _bt_checkkeys(),
> _bt_advance_array_keys() and friends feel complicated.
I agree that it's complicated. That's the main problem that the patch
has, by far. It used to be even more complicated, but it's hard to see
a way to make it a lot simpler at this point. If you can think of a
way to simplify it then I'll definitely give it a go.
Can you elaborate on "more explicit state machine"? That seems like it
could have value by adding more invariants, and making things a bit
more explicit in one or two areas. It could also help us to verify
that they hold from assertions. But that isn't really the same thing
as simplification. I wouldn't use that word, at least.
> > + <note>
> > + <para>
> > + Every time an index is searched, the index's
> > + <structname>pg_stat_all_indexes</structname>.<structfield>idx_scan</structfield>
> > + field is incremented. This usually happens once per index scan node
> > + execution, but might take place several times during execution of a scan
> > + that searches for multiple values together. Only queries that use certain
> > + <acronym>SQL</acronym> constructs to search for rows matching any value
> > + out of a list (or an array) of multiple scalar values are affected. See
> > + <xref linkend="functions-comparisons"/> for details.
> > + </para>
> > + </note>
> > +
>
> Is this true even without this patch? Maybe commit this separately.
Yes, it is. The patch doesn't actually change anything in this area.
However, something in this area is new: it's a bit weird (but still
perfectly consistent and logical) that the count shown by
pg_stat_all_indexes.idx_scan will now show a value that is often
influenced by low-level implementation details now. Things that are
fairly far removed from the SQL query now affect that count -- that
part is new. That's what I had in mind when I wrote this, FWIW.
> The "Only queries ..." sentence feels difficult. Maybe something like
> "For example, queries using IN (...) or = ANY(...) constructs.".
I'll get back to you on this.
> > * _bt_preprocess_keys treats each primitive scan as an independent piece of
> > * work. That structure pushes the responsibility for preprocessing that must
> > * work "across array keys" onto us. This division of labor makes sense once
> > * you consider that we're typically called no more than once per btrescan,
> > * whereas _bt_preprocess_keys is always called once per primitive index scan.
>
> "That structure ..." is a garden-path sentence. I kept parsing "that
> must work" as one unit, the same way as "that structure", and it didn't
> make sense. Took me many re-reads to parse it correctly. Now that I get
> it, it doesn't bother me anymore, but maybe it could be rephrased.
I'll do that ahead of the next revision.
> Is there _any_ situation where _bt_preprocess_array_keys() is called
> more than once per btrescan?
No. Note that we don't know the scan direction within
_bt_preprocess_array_keys(). We need a separate function to set up the
array keys to their initial positions (this is nothing new).
> > /*
> > * Look up the appropriate comparison operator in the opfamily.
> > *
> > * Note: it's possible that this would fail, if the opfamily is
> > * incomplete, but it seems quite unlikely that an opfamily would omit
> > * non-cross-type comparison operators for any datatype that it supports
> > * at all. ...
> > */
>
> I agree that's unlikely. I cannot come up with an example where you
> would have cross-type operators between A and B, but no same-type
> operators between B and B. For any real-world opfamily, that would be an
> omission you'd probably want to fix.
>
> Still I wonder if we could easily fall back if it doesn't exist? And
> maybe add a check in the 'opr_sanity' test for that.
I'll see about an opr_sanity test.
> In _bt_readpage():
> > if (!so->firstPage && !numArrayKeys && minoff < maxoff)
> > {
>
> It's sad to disable this optimization completely for array keys. It's
> actually a regression from current master, isn't it? There's no
> fundamental reason we couldn't do it for array keys so I think we should
> do it.
I'd say whether or not there's any kind of regression in this area is
quite ambiguous, though in a way that isn't really worth discussing
now. If it makes sense to extend something like this optimization to
array keys (or to add a roughly equivalent optimization), then we
should do it. Otherwise we shouldn't.
Note that the patch actually disables two distinct and independent
optimizations when the scan has array keys. Both of these were added
by recent commit e0b1ee17, but they are still independent things. They
are:
1. This skipping thing inside _bt_readpage, which you've highlighted.
This is only applied on the second or subsequent leaf page read by the
scan. Right now, in the case of a scan with array keys, that means the
second or subsequent page from the current primitive index scan --
which doesn't seem particularly principled to me.
I'd need to invent a heuristic that works with my design to adapt the
optimization. Plus I'd need to be able to invalidate the precheck
whenever the array keys advanced. And I'd probably need a way of
guessing whether or not it's likely that the arrays will advance,
ahead of time, so that the precheck doesn't almost always go to waste,
in a way that just doesn't make sense.
Note that all required scan keys are relevant here. I like to think of
plain required equality strategy scan keys without any array as
"degenerate single value arrays". Something similar can be said of
inequality strategy required scan keys (those required in the
*current* scan direction), too. So it's not as if I can "just do the
precheck stuff for the non-array scan keys". All required scan keys
are virtually the same thing as required array-type scan keys -- they
can trigger "roll over", affecting array key advancement for the scan
keys that are associated with arrays.
2. The optimization that has _bt_checkkeys skip non-required scan keys
that are *only* required in the direction *opposite* the current scan
direction -- this can work even without any precheck from
_bt_readpage.
Note that this second optimization relies on various behaviors in
_bt_first() that make it impossible for _bt_checkkeys() to ever see a
tuple that could fail to satisfy such a scan key -- we must always
have passed over non-matching tuples, thanks to _bt_first(). That
prevents my patch with a problem: the logic for determining whether or
not we need a new primitive index scan only promises to never require
the scan to grovel through many leaf pages that _bt_first() could and
should just skip over instead. This new logic makes no promises about
skipping over small numbers of tuples. So it's possible that
_bt_checkkeys() will see a handful of tuples "after the end of the
_bt_first-wise primitive index scan", but "before the _bt_first-wise
start of the next would-be primitive index scan".
Note that this stuff matters even without bringing optimization 2 into
it. There are similar considerations for required equality strategy
scan keys, which (by definition) must be required in both scan
directions. The new mechanism must never act as if it's past the end
of matches in the current scan direction, when in fact it's really
before the beginning of matches (that would lead to totally ignoring a
group of equal matches). The existing _bt_checkkeys() logic can't
really tell the difference on its own, since it only has an = operator
to work with (well, I guess it knows about this context, since there
is a comment about the dependency on _bt_first behaviors in
_bt_checkkeys on HEAD -- very old comments).
> _bt_checkkeys() is called in an assertion in _bt_readpage, but it has
> the side-effect of advancing the array keys. Side-effects from an
> assertion seems problematic.
I agree that that's a concern, but just to be clear: there are no
side-effects presently. You can't mix the array stuff with the
optimization stuff. We won't actually call _bt_checkkeys() in an
assertion when it can cause side-effects.
Assuming that we ultimately conclude that the optimizations *aren't*
worth preserving in any form, it might still be worth making it
obvious that the assertions have no side-effects. But that question is
unsettled right now.
Thanks for the review!
I'll try to get the next revision out soon. It'll also have bug fixes
for mark + restore and for a similar issue seen when the scan changes
direction in just the wrong way. (In short, the array key state
machine can be confused about scan direction in certain corner cases.)
--
Peter Geoghegan
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan
2023-11-07 12:20 Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan Matthias van de Meent <[email protected]>
2023-11-08 01:53 ` Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan Peter Geoghegan <[email protected]>
2023-11-11 21:08 ` Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan Matthias van de Meent <[email protected]>
2023-11-21 02:52 ` Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan Peter Geoghegan <[email protected]>
2023-11-27 13:39 ` Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan Heikki Linnakangas <[email protected]>
2023-12-05 03:25 ` Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan Peter Geoghegan <[email protected]>
@ 2023-12-05 05:01 ` Peter Geoghegan <[email protected]>
0 siblings, 0 replies; 12+ messages in thread
From: Peter Geoghegan @ 2023-12-05 05:01 UTC (permalink / raw)
To: Heikki Linnakangas <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>; Tom Lane <[email protected]>; Tomas Vondra <[email protected]>; Jeff Davis <[email protected]>; benoit <[email protected]>; Alexander Korotkov <[email protected]>; Matthias van de Meent <[email protected]>
On Mon, Dec 4, 2023 at 7:25 PM Peter Geoghegan <[email protected]> wrote:
> 2. The optimization that has _bt_checkkeys skip non-required scan keys
> that are *only* required in the direction *opposite* the current scan
> direction -- this can work even without any precheck from
> _bt_readpage.
>
> Note that this second optimization relies on various behaviors in
> _bt_first() that make it impossible for _bt_checkkeys() to ever see a
> tuple that could fail to satisfy such a scan key -- we must always
> have passed over non-matching tuples, thanks to _bt_first(). That
> prevents my patch with a problem: the logic for determining whether or
> not we need a new primitive index scan only promises to never require
> the scan to grovel through many leaf pages that _bt_first() could and
> should just skip over instead. This new logic makes no promises about
> skipping over small numbers of tuples. So it's possible that
> _bt_checkkeys() will see a handful of tuples "after the end of the
> _bt_first-wise primitive index scan", but "before the _bt_first-wise
> start of the next would-be primitive index scan".
BTW, I have my doubts about this actually being correct without the
patch. The following comment block appears above _bt_preprocess_keys:
* Note that one reason we need direction-sensitive required-key flags is
* precisely that we may not be able to eliminate redundant keys. Suppose
* we have "x > 4::int AND x > 10::bigint", and we are unable to determine
* which key is more restrictive for lack of a suitable cross-type operator.
* _bt_first will arbitrarily pick one of the keys to do the initial
* positioning with. If it picks x > 4, then the x > 10 condition will fail
* until we reach index entries > 10; but we can't stop the scan just because
* x > 10 is failing. On the other hand, if we are scanning backwards, then
* failure of either key is indeed enough to stop the scan. (In general, when
* inequality keys are present, the initial-positioning code only promises to
* position before the first possible match, not exactly at the first match,
* for a forward scan; or after the last match for a backward scan.)
As I understand it, this might still be okay, because the optimization
in question from Alexander's commit e0b1ee17 (what I've called
optimization 2) is careful about NULLs, which were the one case that
definitely had problems. Note that IS NOT NULL works kind of like
WHERE foo < NULL here (see old bug fix commit 882368e8, "Fix btree
stop-at-nulls logic properly", for more context on this NULLs
behavior).
In any case, my patch isn't compatible with "optimization 2" (as in my
tests break in a rather obvious way) due to a behavior that these old
comments claim is normal within any scan (or perhaps normal in any
scan with scan keys that couldn't be deemed redundant due to a lack of
cross-type support in the opfamily).
Something has to be wrong here -- could just be the comment, I
suppose. But I find it easy to believe that Alexander's commit
e0b1ee17 might not have been properly tested with opfamilies that lack
a suitable cross-type operator. That's a pretty niche thing. (My patch
doesn't need that niche thing to be present to easily break when
combined with "optimization 2", which could hint at an existing and
far more subtle problem.)
--
Peter Geoghegan
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan
2023-11-07 12:20 Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan Matthias van de Meent <[email protected]>
2023-11-08 01:53 ` Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan Peter Geoghegan <[email protected]>
2023-11-11 21:08 ` Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan Matthias van de Meent <[email protected]>
2023-11-21 02:52 ` Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan Peter Geoghegan <[email protected]>
@ 2023-11-28 12:29 ` Tomas Vondra <[email protected]>
2 siblings, 0 replies; 12+ messages in thread
From: Tomas Vondra @ 2023-11-28 12:29 UTC (permalink / raw)
To: Peter Geoghegan <[email protected]>; Matthias van de Meent <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>; Tom Lane <[email protected]>; Jeff Davis <[email protected]>; benoit <[email protected]>; Alexander Korotkov <[email protected]>
On 11/21/23 03:52, Peter Geoghegan wrote:
> On Sat, Nov 11, 2023 at 1:08 PM Matthias van de Meent
> <[email protected]> wrote:
>> Thanks. Here's my review of the btree-related code:
>
> Attached is v7.
>
I haven't looked at the code, but I decided to do a bit of blackbox perf
and stress testing, to get some feeling of what to expect in terms of
performance improvements, and see if there happen to be some unexpected
regressions. Attached is a couple simple bash scripts doing a
brute-force test with tables of different size / data distribution,
number of values in the SAOP expression, etc.
And a PDF visualizing the comparing the results between master and build
with the patch applied. First group of columns is master, then patched,
and then (patched/master) comparison, with green=faster, red=slower. The
columns are for different number of values in the SAOP condition.
Overall, the results look pretty good, with consistent speedups of up to
~30% for large number of values (SAOP with 1000 elements). There's a
couple blips where the performance regresses, also by up to ~30%. It's
too regular to be a random variation (it affects different combinations
of parameters, tablesizes), but it seems to only affect one of the two
machines I used for testing. Interestingly enough, it's the newer one.
I'm not convinced this is a problem we have to solve. It's possible it
only affects cases that are implausible in practice (the script forces a
particular scan type, and maybe it would not be picked in practice). But
maybe it's fixable ...
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Attachments:
[application/pdf] saop-benchmark.pdf (245.4K, ../../[email protected]/2-saop-benchmark.pdf)
download
[application/x-shellscript] run-all.sh (470B, ../../[email protected]/3-run-all.sh)
download
[application/x-shellscript] run.sh (3.5K, ../../[email protected]/4-run.sh)
download
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan
2023-11-07 12:20 Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan Matthias van de Meent <[email protected]>
2023-11-08 01:53 ` Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan Peter Geoghegan <[email protected]>
2023-11-11 21:08 ` Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan Matthias van de Meent <[email protected]>
2023-11-21 02:52 ` Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan Peter Geoghegan <[email protected]>
@ 2023-12-09 18:38 ` Peter Geoghegan <[email protected]>
2 siblings, 0 replies; 12+ messages in thread
From: Peter Geoghegan @ 2023-12-09 18:38 UTC (permalink / raw)
To: Matthias van de Meent <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>; Tom Lane <[email protected]>; Tomas Vondra <[email protected]>; Jeff Davis <[email protected]>; benoit <[email protected]>; Alexander Korotkov <[email protected]>; Heikki Linnakangas <[email protected]>
On Mon, Nov 20, 2023 at 6:52 PM Peter Geoghegan <[email protected]> wrote:
> It should be noted that the patch isn't strictly guaranteed to always
> read fewer index pages than master, for a given query plan and index.
> This is by design. Though the patch comes close, it's not quite a
> certainty. There are known cases where the patch reads the occasional
> extra page (relative to what master would have done under the same
> circumstances). These are cases where the implementation just cannot
> know for sure whether the next/sibling leaf page has key space covered
> by any of the scan's array keys (at least not in a way that seems
> practical). The implementation has simple heuristics that infer (a
> polite word for "make an educated guess") about what will be found on
> the next page. Theoretically we could be more conservative in how we
> go about this, but that seems like a bad idea to me. It's really easy
> to find cases where the maximally conservative approach loses by a
> lot, and really hard to show cases where it wins at all.
Attached is v8, which pretty much rips all of this stuff out.
I definitely had a point when I said that it made sense to be
optimistic about finding matches on the next page in respect of any
truncated -inf attributes in high keys, though. And so we still do
that much in v8. But, there is no reason why we need to go any further
than that -- there is no reason why we should *also* be optimistic
about *untruncated* high key/finaltup attributes that *aren't* exact
matches for any of the scan's required array keys finding exact
matches once we move onto the next sibling page.
I reached this conclusion when working on a fix for the low
cardinality index regression that Tomas' tests brought to my attention
[1]. I started out with the intention of just fixing that one case, in
a very targeted way, but quickly realized that it made almost no sense
to just limit myself to the low cardinality cases. Even with Tomas'
problematic low cardinality test cases, I saw untruncated high key
attributes that were "close by to matching tuples" -- they just
weren't close enough (i.e. exactly on the next leaf page) for us to
actually win (so v7 lost). Being almost correct again and again, but
still losing again and again is a good sign that certain basic
assumptions were faulty (at least if it's realistic, which it was in
this instance).
To be clear, and to repeat, even in v8 we'll still "make guesses"
about -inf truncated attributes. But it's a much more limited form of
guessing. If we didn't at least do the -inf thing, then backwards
scans would weirdly work better than forward scans in some cases -- a
particular concern with queries that have index quals for each of
multiple columns. I don't think that this remaining "speculative"
behavior needs to be discussed at very much length in code comments,
though. That's why v8 is a great deal simpler than v7 was here. No
more huge comment block at the end of the new _bt_checkkeys.
Notable stuff that *hasn't* changed from v7:
I'm posting this v8 having not yet worked through all of Heikki's
feedback. In particular, v8 doesn't deal with the relatively hard
question of what to do about the optimizations added by Alexander
Korotkov's commit e0b1ee17 (should I keep them disabled, selectively
re-enable one or both optimizations, or something else?). This is
partly due to at least one of the optimizations having problems of
their own that are still outstanding [2]. I also wanted to get a
revision out before travelling to Prague for PGConf.EU, which will be
followed by other Christmas travel. That's likely to keep me away from
the patch for weeks (that, plus I'm moving to NYC in early January).
So I just ran out of time to do absolutely everything.
Other notable changes:
* Bug fixes for cases where the array state machine gets confused by a
change in the scan direction, plus similar cases involving mark and
restore processing.
I'm not entirely happy with my approach here (mostly referring to the
new code in _bt_steppage here). Feels like it needs to be a little
better integrated with mark/restore processing.
No doubt Heikki will have his own doubts about this. I've included my
test cases for the issues in this area. The problems are really hard
to reproduce, and writing these tests took a surprisingly large amount
of effort. The tests might not be suitable for commit, but you really
need to see the test cases to be able to review the code efficiently.
It's just fiddly.
* I've managed to make the array state machine just a little more
streamlined compared to v7.
Minor code polishing, not really worth describing in detail.
* Addressed concerns about incomplete opfamilies not working with the
patch by updating the error message within
_bt_preprocess_array_keys/_bt_sort_array_cmp_setup. It now exactly
matches the similar one in _bt_first.
I don't think that we need any new opr_sanity tests, since we already
have one for this. Making the error message match the one in _bt_first
ensures that anybody that runs into a problem here will see the same
error message that they'd have seen on earlier versions, anyway.
It's a more useful error compared to the one from v7 (in that it names
the index and its attribute directly). Plus it's good to be
consistent.
I don't see any potential for the underlying _bt_sort_array_cmp_setup
behavior to be seen as a regression, in terms of our ability to cope
with incomplete opfamilies (compared to earlier Postgres versions).
Opfamilies that lack a cross-type ORDER proc mixed with queries that
use the corresponding cross-type = operator were always very dicey.
That situation isn't meaningfully different with the patch.
(Actually, this isn't 100% true in the case of queries + indexes with
non-required arrays specifically -- they'll need a 3-way comparator in
_bt_preprocess_array_keys/_bt_sort_array_cmp_setup, and yet *won't*
need one moments later, in _bt_first. This is because non-required
scan keys don't end up in _bt_first's insertion scan key at all, in
general. This distinction just seems pedantic, though. We're talking
about a case where things accidentally failed to fail in previous
versions, for some queries but not most queries. Now it'll fail in
exactly the same way in slightly more cases. In reality, affected
opfamilies are practically non-existent, so this is a hypothetical
upon a hypothetical.)
[1] https://postgr.es/m/CAH2-WzmtV7XEWxf_rP1pw=vyDjGLi__zGOy6Me5MovR3e1kfdg@mail.gmail.com
[2] https://postgr.es/m/CAH2-Wzn0LeLcb1PdBnK0xisz8NpHkxRrMr3NWJ+KOK-WZ+QtTQ@mail.gmail.com
--
Peter Geoghegan
Attachments:
[application/octet-stream] v8-0001-Enhance-nbtree-ScalarArrayOp-execution.patch (162.9K, ../../CAH2-WzkXJnHOuaonxm4xGPXU4n8D6VS2kzdmSy929nmiYYXBeA@mail.gmail.com/2-v8-0001-Enhance-nbtree-ScalarArrayOp-execution.patch)
download | inline diff:
From 947f6c9272ab36ff858ee0568c1f51d36b1c2f19 Mon Sep 17 00:00:00 2001
From: Peter Geoghegan <[email protected]>
Date: Sat, 17 Jun 2023 17:03:36 -0700
Subject: [PATCH v8] Enhance nbtree ScalarArrayOp execution.
Commit 9e8da0f7 taught nbtree to handle ScalarArrayOpExpr quals
natively. This works by pushing down the full context (the array keys)
to the nbtree index AM, enabling it to execute multiple primitive index
scans that the planner treats as one continuous index scan/index path.
This earlier enhancement enabled nbtree ScalarArrayOp index-only scans.
It also allowed scans with ScalarArrayOp quals to return ordered results
(with some notable restrictions, described further down).
Take this general approach a lot further: teach nbtree SAOP index scans
to determine how best to execute ScalarArrayOp scans (how many primitive
index scans to use under the hood) by applying information about the
physical characteristics of the index at runtime. This approach can be
far more efficient. Many cases that previously required thousands of
index descents now require as few as one single index descent. And, all
SAOP scans reliably avoid duplicative leaf page accesses (just like any
other nbtree index scan).
The array state machine now advances using binary searches for the array
element that best matches the next tuple's attribute value. This whole
process makes required scan key arrays (i.e. arrays from scan keys that
can terminate the scan) ratchet forward in lockstep with the index scan.
Non-required arrays (i.e. arrays from scan keys that can only exclude
non-matching tuples) are for the most part advanced via this same search
process. We just can't assume a fixed relationship between the current
element of any non-required array and the progress of the index scan
through the index's key space (that would be wrong).
Naturally, only required SAOP scan keys trigger skipping over leaf pages
(non-required arrays cannot safely end or start primitive index scans).
Consequently, index scans of a composite index with (say) a high-order
inequality scan key (which we'll mark required) and a low-order SAOP
scan key (which we'll mark non-required) will now reliably output rows
in index order. Such scans are always executed as one large index scan
under the hood, which is obviously the most efficient way to do it, for
the usual reason (no more wasting cycles on repeat leaf page accesses).
Generalizing SAOP execution along these lines removes any question of
index scans outputting tuples in any order that isn't the index's order.
This allow us to remove various special cases from the planner -- which
in turn makes the nbtree work more widely applicable and more effective.
Bugfix commit 807a40c5 taught the planner to avoid generating unsafe
path keys: path keys on a multicolumn index path, with a SAOP clause on
any attribute beyond the first/most significant attribute. These cases
are now all safe, so we go back to generating path keys without regard
for the presence of SAOP clauses (just like with any other clause type).
Also undo changes from follow-up bugfix commit a4523c5a, which taught
the planner to produce alternative index paths without any low-order
ScalarArrayOpExpr quals (making the SAOP quals into filter quals).
We'll no longer generate these alternative paths, which can no longer
offer any advantage over the index qual paths that we do still generate.
Affected queries thereby avoid all of the disadvantages that come from
using filter quals within index scan nodes. In particular, they can
avoid the extra heap page accesses previously incurred when using filter
quals to exclude non-matching tuples (index quals can be used instead).
This shift is expected to be fairly common in real world applications,
especially with queries that have multiple SAOPs that can now all be
used as index quals when scanning a composite index. Queries with
low-order SAOPs (especially non-required ones) are also likely to see a
significant reduction in heap page accesses.
Author: Peter Geoghegan <[email protected]>
Reviewed-By: Heikki Linnakangas <[email protected]>
Reviewed-By: Matthias van de Meent <[email protected]>
Reviewed-By: Tomas Vondra <[email protected]>
Discussion: https://postgr.es/m/CAH2-Wz=ksvN_sjcnD1+Bt-WtifRA5ok48aDYnq3pkKhxgMQpcw@mail.gmail.com
---
src/include/access/nbtree.h | 47 +-
src/backend/access/nbtree/nbtree.c | 80 +-
src/backend/access/nbtree/nbtsearch.c | 119 +-
src/backend/access/nbtree/nbtutils.c | 1814 ++++++++++++++++++--
src/backend/optimizer/path/indxpath.c | 86 +-
src/backend/utils/adt/selfuncs.c | 122 +-
doc/src/sgml/monitoring.sgml | 15 +
src/test/regress/expected/btree_index.out | 479 ++++++
src/test/regress/expected/create_index.out | 31 +-
src/test/regress/expected/join.out | 5 +-
src/test/regress/sql/btree_index.sql | 147 ++
src/test/regress/sql/create_index.sql | 10 +-
12 files changed, 2599 insertions(+), 356 deletions(-)
diff --git a/src/include/access/nbtree.h b/src/include/access/nbtree.h
index 5e083591a..ee15b0f93 100644
--- a/src/include/access/nbtree.h
+++ b/src/include/access/nbtree.h
@@ -960,7 +960,7 @@ typedef struct BTScanPosData
* moreLeft and moreRight track whether we think there may be matching
* index entries to the left and right of the current page, respectively.
* We can clear the appropriate one of these flags when _bt_checkkeys()
- * returns continuescan = false.
+ * sets BTReadPageState.continuescan = false.
*/
bool moreLeft;
bool moreRight;
@@ -1024,7 +1024,6 @@ typedef struct BTArrayKeyInfo
{
int scan_key; /* index of associated key in arrayKeyData */
int cur_elem; /* index of current element in elem_values */
- int mark_elem; /* index of marked element in elem_values */
int num_elems; /* number of elems in current array value */
Datum *elem_values; /* array of num_elems Datums */
} BTArrayKeyInfo;
@@ -1038,13 +1037,14 @@ typedef struct BTScanOpaqueData
/* workspace for SK_SEARCHARRAY support */
ScanKey arrayKeyData; /* modified copy of scan->keyData */
- bool arraysStarted; /* Started array keys, but have yet to "reach
- * past the end" of all arrays? */
int numArrayKeys; /* number of equality-type array keys (-1 if
* there are any unsatisfiable array keys) */
- int arrayKeyCount; /* count indicating number of array scan keys
- * processed */
+ ScanDirection advanceDir; /* Scan direction when arrays last advanced */
+ bool needPrimScan; /* Need primscan to continue in advanceDir? */
BTArrayKeyInfo *arrayKeys; /* info about each equality-type array key */
+ FmgrInfo *orderProcs; /* ORDER procs for equality constraint keys */
+ int numPrimScans; /* Running tally of # primitive index scans
+ * (used to coordinate parallel workers) */
MemoryContext arrayContext; /* scan-lifespan context for array data */
/* info about killed items if any (killedItems is NULL if never used) */
@@ -1078,6 +1078,29 @@ typedef struct BTScanOpaqueData
typedef BTScanOpaqueData *BTScanOpaque;
+/*
+ * _bt_readpage state used across _bt_checkkeys calls for a page
+ *
+ * When _bt_readpage is called during a forward scan that has one or more
+ * equality-type SK_SEARCHARRAY scan keys, it has an extra responsibility: to
+ * set up information about the final tuple from the page. This must happen
+ * before the first call to _bt_checkkeys. _bt_checkkeys uses the final tuple
+ * to manage advancement of the scan's array keys more efficiently.
+ */
+typedef struct BTReadPageState
+{
+ /* Input parameters, set by _bt_readpage */
+ ScanDirection dir; /* current scan direction */
+ IndexTuple finaltup; /* final tuple (high key for forward scans) */
+
+ /* Output parameters, set by _bt_checkkeys */
+ bool continuescan; /* Terminate ongoing (primitive) index scan? */
+
+ /* Private _bt_checkkeys-managed state */
+ bool finaltupchecked; /* final tuple checked against current
+ * SK_SEARCHARRAY array keys? */
+} BTReadPageState;
+
/*
* We use some private sk_flags bits in preprocessed scan keys. We're allowed
* to use bits 16-31 (see skey.h). The uppermost bits are copied from the
@@ -1085,6 +1108,7 @@ typedef BTScanOpaqueData *BTScanOpaque;
*/
#define SK_BT_REQFWD 0x00010000 /* required to continue forward scan */
#define SK_BT_REQBKWD 0x00020000 /* required to continue backward scan */
+#define SK_BT_RDDNARRAY 0x00040000 /* redundant in array preprocessing */
#define SK_BT_INDOPTION_SHIFT 24 /* must clear the above bits */
#define SK_BT_DESC (INDOPTION_DESC << SK_BT_INDOPTION_SHIFT)
#define SK_BT_NULLS_FIRST (INDOPTION_NULLS_FIRST << SK_BT_INDOPTION_SHIFT)
@@ -1155,7 +1179,7 @@ extern bool btcanreturn(Relation index, int attno);
extern bool _bt_parallel_seize(IndexScanDesc scan, BlockNumber *pageno);
extern void _bt_parallel_release(IndexScanDesc scan, BlockNumber scan_page);
extern void _bt_parallel_done(IndexScanDesc scan);
-extern void _bt_parallel_advance_array_keys(IndexScanDesc scan);
+extern void _bt_parallel_next_primitive_scan(IndexScanDesc scan);
/*
* prototypes for functions in nbtdedup.c
@@ -1248,12 +1272,11 @@ extern BTScanInsert _bt_mkscankey(Relation rel, IndexTuple itup);
extern void _bt_freestack(BTStack stack);
extern void _bt_preprocess_array_keys(IndexScanDesc scan);
extern void _bt_start_array_keys(IndexScanDesc scan, ScanDirection dir);
-extern bool _bt_advance_array_keys(IndexScanDesc scan, ScanDirection dir);
-extern void _bt_mark_array_keys(IndexScanDesc scan);
-extern void _bt_restore_array_keys(IndexScanDesc scan);
+extern bool _bt_array_keys_remain(IndexScanDesc scan, ScanDirection dir);
+extern void _bt_rewind_array_keys(IndexScanDesc scan);
extern void _bt_preprocess_keys(IndexScanDesc scan);
-extern bool _bt_checkkeys(IndexScanDesc scan, IndexTuple tuple,
- int tupnatts, ScanDirection dir, bool *continuescan,
+extern bool _bt_checkkeys(IndexScanDesc scan, BTReadPageState *pstate,
+ IndexTuple tuple, bool finaltup, int tupnatts,
bool requiredMatchedByPrecheck);
extern void _bt_killitems(IndexScanDesc scan);
extern BTCycleId _bt_vacuum_cycleid(Relation rel);
diff --git a/src/backend/access/nbtree/nbtree.c b/src/backend/access/nbtree/nbtree.c
index 6c8cd93fa..917af48e8 100644
--- a/src/backend/access/nbtree/nbtree.c
+++ b/src/backend/access/nbtree/nbtree.c
@@ -48,8 +48,8 @@
* BTPARALLEL_IDLE indicates that no backend is currently advancing the scan
* to a new page; some process can start doing that.
*
- * BTPARALLEL_DONE indicates that the scan is complete (including error exit).
- * We reach this state once for every distinct combination of array keys.
+ * BTPARALLEL_DONE indicates that the primitive index scan is complete
+ * (including error exit). Reached once per primitive index scan.
*/
typedef enum
{
@@ -69,8 +69,8 @@ typedef struct BTParallelScanDescData
BTPS_State btps_pageStatus; /* indicates whether next page is
* available for scan. see above for
* possible states of parallel scan. */
- int btps_arrayKeyCount; /* count indicating number of array scan
- * keys processed by parallel scan */
+ int btps_numPrimScans; /* count indicating number of primitive
+ * index scans (used with array keys) */
slock_t btps_mutex; /* protects above variables */
ConditionVariable btps_cv; /* used to synchronize parallel scan */
} BTParallelScanDescData;
@@ -235,7 +235,7 @@ btgettuple(IndexScanDesc scan, ScanDirection dir)
_bt_start_array_keys(scan, dir);
}
- /* This loop handles advancing to the next array elements, if any */
+ /* Each loop iteration performs another primitive index scan */
do
{
/*
@@ -277,8 +277,8 @@ btgettuple(IndexScanDesc scan, ScanDirection dir)
/* If we have a tuple, return it ... */
if (res)
break;
- /* ... otherwise see if we have more array keys to deal with */
- } while (so->numArrayKeys && _bt_advance_array_keys(scan, dir));
+ /* ... otherwise see if we need another primitive index scan */
+ } while (so->numArrayKeys && _bt_array_keys_remain(scan, dir));
return res;
}
@@ -305,7 +305,7 @@ btgetbitmap(IndexScanDesc scan, TIDBitmap *tbm)
_bt_start_array_keys(scan, ForwardScanDirection);
}
- /* This loop handles advancing to the next array elements, if any */
+ /* Each loop iteration performs another primitive index scan */
do
{
/* Fetch the first page & tuple */
@@ -335,8 +335,8 @@ btgetbitmap(IndexScanDesc scan, TIDBitmap *tbm)
ntids++;
}
}
- /* Now see if we have more array keys to deal with */
- } while (so->numArrayKeys && _bt_advance_array_keys(scan, ForwardScanDirection));
+ /* Now see if we need another primitive index scan */
+ } while (so->numArrayKeys && _bt_array_keys_remain(scan, ForwardScanDirection));
return ntids;
}
@@ -366,9 +366,11 @@ btbeginscan(Relation rel, int nkeys, int norderbys)
so->keyData = NULL;
so->arrayKeyData = NULL; /* assume no array keys for now */
- so->arraysStarted = false;
so->numArrayKeys = 0;
+ so->advanceDir = NoMovementScanDirection;
+ so->needPrimScan = false;
so->arrayKeys = NULL;
+ so->orderProcs = NULL;
so->arrayContext = NULL;
so->killedItems = NULL; /* until needed */
@@ -408,7 +410,9 @@ btrescan(IndexScanDesc scan, ScanKey scankey, int nscankeys,
}
so->markItemIndex = -1;
- so->arrayKeyCount = 0;
+ so->advanceDir = NoMovementScanDirection;
+ so->needPrimScan = false;
+ so->numPrimScans = 0;
so->firstPage = false;
BTScanPosUnpinIfPinned(so->markPos);
BTScanPosInvalidate(so->markPos);
@@ -508,10 +512,6 @@ btmarkpos(IndexScanDesc scan)
BTScanPosInvalidate(so->markPos);
so->markItemIndex = -1;
}
-
- /* Also record the current positions of any array keys */
- if (so->numArrayKeys)
- _bt_mark_array_keys(scan);
}
/*
@@ -522,10 +522,6 @@ btrestrpos(IndexScanDesc scan)
{
BTScanOpaque so = (BTScanOpaque) scan->opaque;
- /* Restore the marked positions of any array keys */
- if (so->numArrayKeys)
- _bt_restore_array_keys(scan);
-
if (so->markItemIndex >= 0)
{
/*
@@ -564,6 +560,9 @@ btrestrpos(IndexScanDesc scan)
if (so->currTuples)
memcpy(so->currTuples, so->markTuples,
so->markPos.nextTupleOffset);
+ /* Rewind the scan's array keys, if any */
+ if (so->numArrayKeys)
+ _bt_rewind_array_keys(scan);
}
else
BTScanPosInvalidate(so->currPos);
@@ -590,7 +589,7 @@ btinitparallelscan(void *target)
SpinLockInit(&bt_target->btps_mutex);
bt_target->btps_scanPage = InvalidBlockNumber;
bt_target->btps_pageStatus = BTPARALLEL_NOT_INITIALIZED;
- bt_target->btps_arrayKeyCount = 0;
+ bt_target->btps_numPrimScans = 0;
ConditionVariableInit(&bt_target->btps_cv);
}
@@ -616,7 +615,7 @@ btparallelrescan(IndexScanDesc scan)
SpinLockAcquire(&btscan->btps_mutex);
btscan->btps_scanPage = InvalidBlockNumber;
btscan->btps_pageStatus = BTPARALLEL_NOT_INITIALIZED;
- btscan->btps_arrayKeyCount = 0;
+ btscan->btps_numPrimScans = 0;
SpinLockRelease(&btscan->btps_mutex);
}
@@ -627,7 +626,11 @@ btparallelrescan(IndexScanDesc scan)
*
* The return value is true if we successfully seized the scan and false
* if we did not. The latter case occurs if no pages remain for the current
- * set of scankeys.
+ * primitive index scan.
+ *
+ * When array scan keys are in use, each worker process independently advances
+ * its array keys. It's crucial that each worker process never be allowed to
+ * scan a page from before the current scan position.
*
* If the return value is true, *pageno returns the next or current page
* of the scan (depending on the scan direction). An invalid block number
@@ -658,16 +661,17 @@ _bt_parallel_seize(IndexScanDesc scan, BlockNumber *pageno)
SpinLockAcquire(&btscan->btps_mutex);
pageStatus = btscan->btps_pageStatus;
- if (so->arrayKeyCount < btscan->btps_arrayKeyCount)
+ if (so->numPrimScans < btscan->btps_numPrimScans)
{
- /* Parallel scan has already advanced to a new set of scankeys. */
+ /* Top-level scan already moved on to next primitive index scan */
status = false;
}
else if (pageStatus == BTPARALLEL_DONE)
{
/*
- * We're done with this set of scankeys. This may be the end, or
- * there could be more sets to try.
+ * We're done with this primitive index scan. This might have
+ * been the final primitive index scan required, or the top-level
+ * index scan might require additional primitive scans.
*/
status = false;
}
@@ -699,9 +703,12 @@ _bt_parallel_seize(IndexScanDesc scan, BlockNumber *pageno)
void
_bt_parallel_release(IndexScanDesc scan, BlockNumber scan_page)
{
+ BTScanOpaque so PG_USED_FOR_ASSERTS_ONLY = (BTScanOpaque) scan->opaque;
ParallelIndexScanDesc parallel_scan = scan->parallel_scan;
BTParallelScanDesc btscan;
+ Assert(!so->needPrimScan);
+
btscan = (BTParallelScanDesc) OffsetToPointer((void *) parallel_scan,
parallel_scan->ps_offset);
@@ -735,12 +742,11 @@ _bt_parallel_done(IndexScanDesc scan)
parallel_scan->ps_offset);
/*
- * Mark the parallel scan as done for this combination of scan keys,
- * unless some other process already did so. See also
- * _bt_advance_array_keys.
+ * Mark the primitive index scan as done, unless some other process
+ * already did so. See also _bt_array_keys_remain.
*/
SpinLockAcquire(&btscan->btps_mutex);
- if (so->arrayKeyCount >= btscan->btps_arrayKeyCount &&
+ if (so->numPrimScans >= btscan->btps_numPrimScans &&
btscan->btps_pageStatus != BTPARALLEL_DONE)
{
btscan->btps_pageStatus = BTPARALLEL_DONE;
@@ -754,14 +760,14 @@ _bt_parallel_done(IndexScanDesc scan)
}
/*
- * _bt_parallel_advance_array_keys() -- Advances the parallel scan for array
- * keys.
+ * _bt_parallel_next_primitive_scan() -- Advances parallel primitive scan
+ * counter when array keys are in use.
*
- * Updates the count of array keys processed for both local and parallel
+ * Updates the count of primitive index scans for both local and parallel
* scans.
*/
void
-_bt_parallel_advance_array_keys(IndexScanDesc scan)
+_bt_parallel_next_primitive_scan(IndexScanDesc scan)
{
BTScanOpaque so = (BTScanOpaque) scan->opaque;
ParallelIndexScanDesc parallel_scan = scan->parallel_scan;
@@ -770,13 +776,13 @@ _bt_parallel_advance_array_keys(IndexScanDesc scan)
btscan = (BTParallelScanDesc) OffsetToPointer((void *) parallel_scan,
parallel_scan->ps_offset);
- so->arrayKeyCount++;
+ so->numPrimScans++;
SpinLockAcquire(&btscan->btps_mutex);
if (btscan->btps_pageStatus == BTPARALLEL_DONE)
{
btscan->btps_scanPage = InvalidBlockNumber;
btscan->btps_pageStatus = BTPARALLEL_NOT_INITIALIZED;
- btscan->btps_arrayKeyCount++;
+ btscan->btps_numPrimScans++;
}
SpinLockRelease(&btscan->btps_mutex);
}
diff --git a/src/backend/access/nbtree/nbtsearch.c b/src/backend/access/nbtree/nbtsearch.c
index be61b3868..04b7e1f15 100644
--- a/src/backend/access/nbtree/nbtsearch.c
+++ b/src/backend/access/nbtree/nbtsearch.c
@@ -907,7 +907,7 @@ _bt_first(IndexScanDesc scan, ScanDirection dir)
*/
if (!so->qual_ok)
{
- /* Notify any other workers that we're done with this scan key. */
+ /* Notify any other workers that this primitive scan is done */
_bt_parallel_done(scan);
return false;
}
@@ -1527,10 +1527,11 @@ _bt_readpage(IndexScanDesc scan, ScanDirection dir, OffsetNumber offnum)
BTPageOpaque opaque;
OffsetNumber minoff;
OffsetNumber maxoff;
- int itemIndex;
- bool continuescan;
+ BTReadPageState pstate;
+ int numArrayKeys,
+ itemIndex;
int indnatts;
- bool requiredMatchedByPrecheck;
+ bool requiredMatchedByPrecheck = false;
/*
* We must have the buffer pinned and locked, but the usual macro can't be
@@ -1550,8 +1551,13 @@ _bt_readpage(IndexScanDesc scan, ScanDirection dir, OffsetNumber offnum)
_bt_parallel_release(scan, BufferGetBlockNumber(so->currPos.buf));
}
- continuescan = true; /* default assumption */
+ pstate.dir = dir;
+ pstate.finaltup = NULL;
+ pstate.continuescan = true; /* default assumption */
+ pstate.finaltupchecked = false;
indnatts = IndexRelationGetNumberOfAttributes(scan->indexRelation);
+ numArrayKeys = so->numArrayKeys;
+
minoff = P_FIRSTDATAKEY(opaque);
maxoff = PageGetMaxOffsetNumber(page);
@@ -1599,9 +1605,12 @@ _bt_readpage(IndexScanDesc scan, ScanDirection dir, OffsetNumber offnum)
* the last item on the page would give a more precise answer.
*
* We skip this for the first page in the scan to evade the possible
- * slowdown of the point queries.
+ * slowdown of point queries. Never apply the optimization with a scan
+ * that uses array keys, either, since that breaks certain assumptions.
+ * (Our search-type scan keys change whenever _bt_checkkeys advances the
+ * arrays, invalidating any precheck. Tracking all that would be tricky.)
*/
- if (!so->firstPage && minoff < maxoff)
+ if (!so->firstPage && !numArrayKeys && minoff < maxoff)
{
ItemId iid;
IndexTuple itup;
@@ -1610,22 +1619,25 @@ _bt_readpage(IndexScanDesc scan, ScanDirection dir, OffsetNumber offnum)
itup = (IndexTuple) PageGetItem(page, iid);
/*
- * Do the precheck. Note that we pass the pointer to
- * 'requiredMatchedByPrecheck' to 'continuescan' argument. That will
- * set flag to true if all required keys are satisfied and false
- * otherwise.
+ * Flag variable is set when all scan keys that are required in the
+ * current scan direction are satisfied by the last item on the page
*/
- (void) _bt_checkkeys(scan, itup, indnatts, dir,
- &requiredMatchedByPrecheck, false);
- }
- else
- {
- so->firstPage = false;
- requiredMatchedByPrecheck = false;
+ _bt_checkkeys(scan, &pstate, itup, false, indnatts, false);
+ requiredMatchedByPrecheck = pstate.continuescan;
+ pstate.continuescan = true; /* reset */
}
+ so->firstPage = false;
if (ScanDirectionIsForward(dir))
{
+ /* SK_SEARCHARRAY forward scans must provide high key up front */
+ if (numArrayKeys && !P_RIGHTMOST(opaque))
+ {
+ ItemId iid = PageGetItemId(page, P_HIKEY);
+
+ pstate.finaltup = (IndexTuple) PageGetItem(page, iid);
+ }
+
/* load items[] in ascending order */
itemIndex = 0;
@@ -1650,8 +1662,8 @@ _bt_readpage(IndexScanDesc scan, ScanDirection dir, OffsetNumber offnum)
itup = (IndexTuple) PageGetItem(page, iid);
Assert(!BTreeTupleIsPivot(itup));
- passes_quals = _bt_checkkeys(scan, itup, indnatts, dir,
- &continuescan, requiredMatchedByPrecheck);
+ passes_quals = _bt_checkkeys(scan, &pstate, itup, false, indnatts,
+ requiredMatchedByPrecheck);
/*
* If the result of prechecking required keys was true, then in
@@ -1659,8 +1671,8 @@ _bt_readpage(IndexScanDesc scan, ScanDirection dir, OffsetNumber offnum)
* result is the same.
*/
Assert(!requiredMatchedByPrecheck ||
- passes_quals == _bt_checkkeys(scan, itup, indnatts, dir,
- &continuescan, false));
+ passes_quals == _bt_checkkeys(scan, &pstate, itup, false,
+ indnatts, false));
if (passes_quals)
{
/* tuple passes all scan key conditions */
@@ -1694,7 +1706,7 @@ _bt_readpage(IndexScanDesc scan, ScanDirection dir, OffsetNumber offnum)
}
}
/* When !continuescan, there can't be any more matches, so stop */
- if (!continuescan)
+ if (!pstate.continuescan)
break;
offnum = OffsetNumberNext(offnum);
@@ -1711,17 +1723,17 @@ _bt_readpage(IndexScanDesc scan, ScanDirection dir, OffsetNumber offnum)
* only appear on non-pivot tuples on the right sibling page are
* common.
*/
- if (continuescan && !P_RIGHTMOST(opaque))
+ if (pstate.continuescan && !P_RIGHTMOST(opaque))
{
ItemId iid = PageGetItemId(page, P_HIKEY);
IndexTuple itup = (IndexTuple) PageGetItem(page, iid);
int truncatt;
truncatt = BTreeTupleGetNAtts(itup, scan->indexRelation);
- _bt_checkkeys(scan, itup, truncatt, dir, &continuescan, false);
+ _bt_checkkeys(scan, &pstate, itup, true, truncatt, false);
}
- if (!continuescan)
+ if (!pstate.continuescan)
so->currPos.moreRight = false;
Assert(itemIndex <= MaxTIDsPerBTreePage);
@@ -1731,6 +1743,14 @@ _bt_readpage(IndexScanDesc scan, ScanDirection dir, OffsetNumber offnum)
}
else
{
+ /* SK_SEARCHARRAY backward scans must provide final tuple up front */
+ if (numArrayKeys && minoff <= maxoff)
+ {
+ ItemId iid = PageGetItemId(page, minoff);
+
+ pstate.finaltup = (IndexTuple) PageGetItem(page, iid);
+ }
+
/* load items[] in descending order */
itemIndex = MaxTIDsPerBTreePage;
@@ -1742,6 +1762,7 @@ _bt_readpage(IndexScanDesc scan, ScanDirection dir, OffsetNumber offnum)
IndexTuple itup;
bool tuple_alive;
bool passes_quals;
+ bool finaltup = (offnum == minoff);
/*
* If the scan specifies not to return killed tuples, then we
@@ -1752,12 +1773,18 @@ _bt_readpage(IndexScanDesc scan, ScanDirection dir, OffsetNumber offnum)
* tuple on the page, we do check the index keys, to prevent
* uselessly advancing to the page to the left. This is similar
* to the high key optimization used by forward scans.
+ *
+ * Separately, _bt_checkkeys actually requires that we call it
+ * with the final non-pivot tuple from the page, if there's one
+ * (final processed tuple, or first tuple in offset number terms).
+ * We must indicate which particular tuple comes last, too.
*/
if (scan->ignore_killed_tuples && ItemIdIsDead(iid))
{
Assert(offnum >= P_FIRSTDATAKEY(opaque));
- if (offnum > P_FIRSTDATAKEY(opaque))
+ if (!finaltup)
{
+ Assert(offnum > minoff);
offnum = OffsetNumberPrev(offnum);
continue;
}
@@ -1770,8 +1797,8 @@ _bt_readpage(IndexScanDesc scan, ScanDirection dir, OffsetNumber offnum)
itup = (IndexTuple) PageGetItem(page, iid);
Assert(!BTreeTupleIsPivot(itup));
- passes_quals = _bt_checkkeys(scan, itup, indnatts, dir,
- &continuescan, requiredMatchedByPrecheck);
+ passes_quals = _bt_checkkeys(scan, &pstate, itup, finaltup,
+ indnatts, requiredMatchedByPrecheck);
/*
* If the result of prechecking required keys was true, then in
@@ -1779,8 +1806,8 @@ _bt_readpage(IndexScanDesc scan, ScanDirection dir, OffsetNumber offnum)
* result is the same.
*/
Assert(!requiredMatchedByPrecheck ||
- passes_quals == _bt_checkkeys(scan, itup, indnatts, dir,
- &continuescan, false));
+ passes_quals == _bt_checkkeys(scan, &pstate, itup,
+ finaltup, indnatts, false));
if (passes_quals && tuple_alive)
{
/* tuple passes all scan key conditions */
@@ -1819,7 +1846,7 @@ _bt_readpage(IndexScanDesc scan, ScanDirection dir, OffsetNumber offnum)
}
}
}
- if (!continuescan)
+ if (!pstate.continuescan)
{
/* there can't be any more matches, so stop */
so->currPos.moreLeft = false;
@@ -1994,6 +2021,20 @@ _bt_steppage(IndexScanDesc scan, ScanDirection dir)
/* Remember we left a page with data */
so->currPos.moreLeft = true;
+ /*
+ * If the scan direction changed since our array keys (if any) last
+ * advanced, we cannot trust _bt_readpage's determination that there
+ * are no matches to be found to the right
+ */
+ if (ScanDirectionIsBackward(so->advanceDir))
+ {
+ Assert(so->numArrayKeys);
+
+ so->currPos.moreRight = true;
+ so->advanceDir = dir;
+ so->needPrimScan = false;
+ }
+
/* release the previous buffer, if pinned */
BTScanPosUnpinIfPinned(so->currPos);
}
@@ -2002,6 +2043,20 @@ _bt_steppage(IndexScanDesc scan, ScanDirection dir)
/* Remember we left a page with data */
so->currPos.moreRight = true;
+ /*
+ * If the scan direction changed since our array keys (if any) last
+ * advanced, we cannot trust _bt_readpage's determination that there
+ * are no matches to be found to the left
+ */
+ if (ScanDirectionIsForward(so->advanceDir))
+ {
+ Assert(so->numArrayKeys);
+
+ so->currPos.moreLeft = true;
+ so->advanceDir = dir;
+ so->needPrimScan = false;
+ }
+
if (scan->parallel_scan != NULL)
{
/*
diff --git a/src/backend/access/nbtree/nbtutils.c b/src/backend/access/nbtree/nbtutils.c
index f25d62b05..1a04a6a1a 100644
--- a/src/backend/access/nbtree/nbtutils.c
+++ b/src/backend/access/nbtree/nbtutils.c
@@ -33,7 +33,7 @@
typedef struct BTSortArrayContext
{
- FmgrInfo flinfo;
+ FmgrInfo *orderproc;
Oid collation;
bool reverse;
} BTSortArrayContext;
@@ -41,15 +41,42 @@ typedef struct BTSortArrayContext
static Datum _bt_find_extreme_element(IndexScanDesc scan, ScanKey skey,
StrategyNumber strat,
Datum *elems, int nelems);
+static void _bt_sort_array_cmp_setup(IndexScanDesc scan, ScanKey skey);
static int _bt_sort_array_elements(IndexScanDesc scan, ScanKey skey,
bool reverse,
Datum *elems, int nelems);
+static int _bt_merge_arrays(IndexScanDesc scan, ScanKey skey, bool reverse,
+ Datum *elems_orig, int nelems_orig,
+ Datum *elems_next, int nelems_next);
static int _bt_compare_array_elements(const void *a, const void *b, void *arg);
+static inline int32 _bt_compare_array_skey(FmgrInfo *orderproc,
+ Datum tupdatum, bool tupnull,
+ Datum arrdatum, ScanKey cur);
+static int _bt_binsrch_array_skey(FmgrInfo *orderproc,
+ bool cur_elem_start, ScanDirection dir,
+ Datum tupdatum, bool tupnull,
+ BTArrayKeyInfo *array, ScanKey cur,
+ int32 *set_elem_result);
+static bool _bt_advance_array_keys_increment(IndexScanDesc scan, ScanDirection dir);
+static bool _bt_tuple_before_array_skeys(IndexScanDesc scan,
+ BTReadPageState *pstate,
+ IndexTuple tuple, int sktrig,
+ bool validtrig);
+static bool _bt_advance_array_keys(IndexScanDesc scan, BTReadPageState *pstate,
+ IndexTuple tuple, int sktrig);
+static void _bt_update_keys_with_arraykeys(IndexScanDesc scan);
+#ifdef USE_ASSERT_CHECKING
+static bool _bt_verify_keys_with_arraykeys(IndexScanDesc scan);
+#endif
static bool _bt_compare_scankey_args(IndexScanDesc scan, ScanKey op,
ScanKey leftarg, ScanKey rightarg,
bool *result);
static bool _bt_fix_scankey_strategy(ScanKey skey, int16 *indoption);
static void _bt_mark_scankey_required(ScanKey skey);
+static bool _bt_check_compare(ScanDirection dir, BTScanOpaque so,
+ IndexTuple tuple, int tupnatts, TupleDesc tupdesc,
+ int numArrayKeys, bool *continuescan, int *ikey,
+ bool requiredMatchedByPrecheck);
static bool _bt_check_rowcompare(ScanKey skey,
IndexTuple tuple, int tupnatts, TupleDesc tupdesc,
ScanDirection dir, bool *continuescan);
@@ -190,13 +217,48 @@ _bt_freestack(BTStack stack)
* If there are any SK_SEARCHARRAY scan keys, deconstruct the array(s) and
* set up BTArrayKeyInfo info for each one that is an equality-type key.
* Prepare modified scan keys in so->arrayKeyData, which will hold the current
- * array elements during each primitive indexscan operation. For inequality
- * array keys, it's sufficient to find the extreme element value and replace
- * the whole array with that scalar value.
+ * array elements.
+ *
+ * _bt_preprocess_keys treats each primitive scan as an independent piece of
+ * work. We perform all preprocessing that must work "across array keys".
+ * This division of labor makes sense once you consider that we're called only
+ * once per btrescan, whereas _bt_preprocess_keys is called once per primitive
+ * index scan.
+ *
+ * Currently we perform two kinds of preprocessing to deal with redundancies.
+ * For inequality array keys, it's sufficient to find the extreme element
+ * value and replace the whole array with that scalar value. This eliminates
+ * all but one array key as redundant. Similarly, we are capable of "merging
+ * together" multiple equality array keys from two or more input scan keys
+ * into a single output scan key that contains only the intersecting array
+ * elements. This can eliminate many redundant array elements, as well as
+ * eliminating whole array scan keys as redundant.
+ *
+ * Note: _bt_start_array_keys actually sets up the cur_elem counters later on,
+ * once the scan direction is known.
*
* Note: the reason we need so->arrayKeyData, rather than just scribbling
* on scan->keyData, is that callers are permitted to call btrescan without
* supplying a new set of scankey data.
+ *
+ * Note: _bt_preprocess_keys is responsible for creating the so->keyData scan
+ * keys used by _bt_checkkeys. Index scans that don't use equality array keys
+ * will have _bt_preprocess_keys treat scan->keyData as input and so->keyData
+ * as output. Scans that use equality array keys have _bt_preprocess_keys
+ * treat so->arrayKeyData (which is our output) as their input, while (as per
+ * usual) outputting so->keyData for _bt_checkkeys. This function adds an
+ * additional layer of indirection that allows _bt_preprocess_keys to more or
+ * less avoid dealing with SK_SEARCHARRAY as a special case.
+ *
+ * Note: _bt_update_keys_with_arraykeys works by updating already-processed
+ * output keys (so->keyData) in-place. It cannot eliminate redundant or
+ * contradictory scan keys. This necessitates having _bt_preprocess_keys
+ * understand that it is unsafe to eliminate "redundant" SK_SEARCHARRAY
+ * equality scan keys on the basis of what is actually just the current array
+ * key values -- it must conservatively assume that such a scan key might no
+ * longer be redundant after the next _bt_update_keys_with_arraykeys call.
+ * Ideally we'd be able to deal with that by eliminating a subset of truly
+ * redundant array keys up-front, but it doesn't seem worth the trouble.
*/
void
_bt_preprocess_array_keys(IndexScanDesc scan)
@@ -204,7 +266,10 @@ _bt_preprocess_array_keys(IndexScanDesc scan)
BTScanOpaque so = (BTScanOpaque) scan->opaque;
int numberOfKeys = scan->numberOfKeys;
int16 *indoption = scan->indexRelation->rd_indoption;
+ int16 nkeyatts = IndexRelationGetNumberOfKeyAttributes(scan->indexRelation);
int numArrayKeys;
+ int lastEqualityArrayAtt = -1;
+ Oid lastOrderProc = InvalidOid;
ScanKey cur;
int i;
MemoryContext oldContext;
@@ -257,6 +322,8 @@ _bt_preprocess_array_keys(IndexScanDesc scan)
/* Allocate space for per-array data in the workspace context */
so->arrayKeys = (BTArrayKeyInfo *) palloc0(numArrayKeys * sizeof(BTArrayKeyInfo));
+ so->orderProcs = (FmgrInfo *) palloc0(nkeyatts * sizeof(FmgrInfo));
+ so->advanceDir = NoMovementScanDirection;
/* Now process each array key */
numArrayKeys = 0;
@@ -273,6 +340,16 @@ _bt_preprocess_array_keys(IndexScanDesc scan)
int j;
cur = &so->arrayKeyData[i];
+
+ /*
+ * Attributes with equality-type scan keys (including but not limited
+ * to array scan keys) will need a 3-way comparison function. Set
+ * that up now. (Avoids repeating work for the same attribute.)
+ */
+ if (cur->sk_strategy == BTEqualStrategyNumber &&
+ !OidIsValid(so->orderProcs[cur->sk_attno - 1].fn_oid))
+ _bt_sort_array_cmp_setup(scan, cur);
+
if (!(cur->sk_flags & SK_SEARCHARRAY))
continue;
@@ -349,6 +426,46 @@ _bt_preprocess_array_keys(IndexScanDesc scan)
(indoption[cur->sk_attno - 1] & INDOPTION_DESC) != 0,
elem_values, num_nonnulls);
+ /*
+ * If this scan key is semantically equivalent to a previous equality
+ * operator array scan key, merge the two arrays together to eliminate
+ * redundant non-intersecting elements (and redundant whole scan keys)
+ */
+ if (lastEqualityArrayAtt == cur->sk_attno &&
+ lastOrderProc == cur->sk_func.fn_oid)
+ {
+ BTArrayKeyInfo *prev = &so->arrayKeys[numArrayKeys - 1];
+
+ Assert(so->arrayKeyData[prev->scan_key].sk_subtype ==
+ cur->sk_subtype);
+
+ num_elems = _bt_merge_arrays(scan, cur,
+ (indoption[cur->sk_attno - 1] & INDOPTION_DESC) != 0,
+ prev->elem_values, prev->num_elems,
+ elem_values, num_elems);
+
+ pfree(elem_values);
+
+ /*
+ * If there are no intersecting elements left from merging this
+ * array into the previous array on the same attribute, the scan
+ * qual is unsatisfiable
+ */
+ if (num_elems == 0)
+ {
+ numArrayKeys = -1;
+ break;
+ }
+
+ /*
+ * Lower the number of elements from the previous array, and mark
+ * this scan key/array as redundant for every primitive index scan
+ */
+ prev->num_elems = num_elems;
+ cur->sk_flags |= SK_BT_RDDNARRAY;
+ continue;
+ }
+
/*
* And set up the BTArrayKeyInfo data.
*/
@@ -356,6 +473,8 @@ _bt_preprocess_array_keys(IndexScanDesc scan)
so->arrayKeys[numArrayKeys].num_elems = num_elems;
so->arrayKeys[numArrayKeys].elem_values = elem_values;
numArrayKeys++;
+ lastEqualityArrayAtt = cur->sk_attno;
+ lastOrderProc = cur->sk_func.fn_oid;
}
so->numArrayKeys = numArrayKeys;
@@ -429,26 +548,28 @@ _bt_find_extreme_element(IndexScanDesc scan, ScanKey skey,
}
/*
- * _bt_sort_array_elements() -- sort and de-dup array elements
+ * _bt_sort_array_cmp_setup() -- Look up array comparison function
*
- * The array elements are sorted in-place, and the new number of elements
- * after duplicate removal is returned.
- *
- * scan and skey identify the index column, whose opfamily determines the
- * comparison semantics. If reverse is true, we sort in descending order.
+ * Sets so->orderProcs[] for scan key's attribute. This is used to sort and
+ * deduplicate the attribute's array (if any). It's also used during binary
+ * searches of the next array key matching index tuples just beyond the range
+ * of the scan's current set of array keys.
*/
-static int
-_bt_sort_array_elements(IndexScanDesc scan, ScanKey skey,
- bool reverse,
- Datum *elems, int nelems)
+static void
+_bt_sort_array_cmp_setup(IndexScanDesc scan, ScanKey skey)
{
+ BTScanOpaque so = (BTScanOpaque) scan->opaque;
Relation rel = scan->indexRelation;
Oid elemtype;
RegProcedure cmp_proc;
- BTSortArrayContext cxt;
+ FmgrInfo *orderproc = &so->orderProcs[skey->sk_attno - 1];
- if (nelems <= 1)
- return nelems; /* no work to do */
+ /*
+ * Should do this for all equality strategy scan keys only (including
+ * those without any array). See _bt_advance_array_keys for details of
+ * why we need an ORDER proc for non-array equality strategy scan keys.
+ */
+ Assert(skey->sk_strategy == BTEqualStrategyNumber);
/*
* Determine the nominal datatype of the array elements. We have to
@@ -462,22 +583,44 @@ _bt_sort_array_elements(IndexScanDesc scan, ScanKey skey,
/*
* Look up the appropriate comparison function in the opfamily.
*
- * Note: it's possible that this would fail, if the opfamily is
- * incomplete, but it seems quite unlikely that an opfamily would omit
- * non-cross-type support functions for any datatype that it supports at
- * all.
+ * Note: it's possible that this would fail, if the opfamily lacks the
+ * required cross-type ORDER proc. But this is no different to the case
+ * where _bt_first fails to find an ORDER proc for its insertion scan key.
*/
cmp_proc = get_opfamily_proc(rel->rd_opfamily[skey->sk_attno - 1],
- elemtype,
- elemtype,
+ rel->rd_opcintype[skey->sk_attno - 1], elemtype,
BTORDER_PROC);
if (!RegProcedureIsValid(cmp_proc))
- elog(ERROR, "missing support function %d(%u,%u) in opfamily %u",
- BTORDER_PROC, elemtype, elemtype,
- rel->rd_opfamily[skey->sk_attno - 1]);
+ elog(ERROR, "missing support function %d(%u,%u) for attribute %d of index \"%s\"",
+ BTORDER_PROC, rel->rd_opcintype[skey->sk_attno - 1], elemtype,
+ skey->sk_attno, RelationGetRelationName(rel));
+
+ /* Save in orderproc entry for attribute */
+ fmgr_info_cxt(cmp_proc, orderproc, so->arrayContext);
+}
+
+/*
+ * _bt_sort_array_elements() -- sort and de-dup array elements
+ *
+ * The array elements are sorted in-place, and the new number of elements
+ * after duplicate removal is returned.
+ *
+ * scan and skey identify the index column, whose opfamily determines the
+ * comparison semantics. If reverse is true, we sort in descending order.
+ */
+static int
+_bt_sort_array_elements(IndexScanDesc scan, ScanKey skey,
+ bool reverse,
+ Datum *elems, int nelems)
+{
+ BTScanOpaque so = (BTScanOpaque) scan->opaque;
+ BTSortArrayContext cxt;
+
+ if (nelems <= 1)
+ return nelems; /* no work to do */
/* Sort the array elements */
- fmgr_info(cmp_proc, &cxt.flinfo);
+ cxt.orderproc = &so->orderProcs[skey->sk_attno - 1];
cxt.collation = skey->sk_collation;
cxt.reverse = reverse;
qsort_arg(elems, nelems, sizeof(Datum),
@@ -488,6 +631,48 @@ _bt_sort_array_elements(IndexScanDesc scan, ScanKey skey,
_bt_compare_array_elements, &cxt);
}
+/*
+ * _bt_merge_arrays() -- merge together duplicate array keys
+ *
+ * Both scan keys have array elements that have already been sorted and
+ * deduplicated.
+ */
+static int
+_bt_merge_arrays(IndexScanDesc scan, ScanKey skey, bool reverse,
+ Datum *elems_orig, int nelems_orig,
+ Datum *elems_next, int nelems_next)
+{
+ BTScanOpaque so = (BTScanOpaque) scan->opaque;
+ BTSortArrayContext cxt;
+ Datum *merged = palloc(sizeof(Datum) * Min(nelems_orig, nelems_next));
+ int merged_nelems = 0;
+
+ /*
+ * Incrementally copy the original array into a temp buffer, skipping over
+ * any items that are missing from the "next" array
+ */
+ cxt.orderproc = &so->orderProcs[skey->sk_attno - 1];
+ cxt.collation = skey->sk_collation;
+ cxt.reverse = reverse;
+ for (int i = 0; i < nelems_orig; i++)
+ {
+ Datum *elem = elems_orig + i;
+
+ if (bsearch_arg(elem, elems_next, nelems_next, sizeof(Datum),
+ _bt_compare_array_elements, &cxt))
+ merged[merged_nelems++] = *elem;
+ }
+
+ /*
+ * Overwrite the original array with temp buffer so that we're only left
+ * with intersecting array elements
+ */
+ memcpy(elems_orig, merged, merged_nelems * sizeof(Datum));
+ pfree(merged);
+
+ return merged_nelems;
+}
+
/*
* qsort_arg comparator for sorting array elements
*/
@@ -499,7 +684,7 @@ _bt_compare_array_elements(const void *a, const void *b, void *arg)
BTSortArrayContext *cxt = (BTSortArrayContext *) arg;
int32 compare;
- compare = DatumGetInt32(FunctionCall2Coll(&cxt->flinfo,
+ compare = DatumGetInt32(FunctionCall2Coll(cxt->orderproc,
cxt->collation,
da, db));
if (cxt->reverse)
@@ -507,6 +692,159 @@ _bt_compare_array_elements(const void *a, const void *b, void *arg)
return compare;
}
+/*
+ * _bt_compare_array_skey() -- apply array comparison function
+ *
+ * Compares caller's tuple attribute value to a scan key/array element.
+ * Helper function used during binary searches of SK_SEARCHARRAY arrays.
+ *
+ * This routine returns:
+ * <0 if tupdatum < arrdatum;
+ * 0 if tupdatum == arrdatum;
+ * >0 if tupdatum > arrdatum.
+ *
+ * This is essentially the same interface as _bt_compare: both functions
+ * compare the value that they're searching for to a binary search pivot.
+ * However, unlike _bt_compare, this function's "tuple argument" comes first,
+ * while its "array/scankey argument" comes second.
+*/
+static inline int32
+_bt_compare_array_skey(FmgrInfo *orderproc,
+ Datum tupdatum, bool tupnull,
+ Datum arrdatum, ScanKey cur)
+{
+ int32 result = 0;
+
+ Assert(cur->sk_strategy == BTEqualStrategyNumber);
+
+ if (tupnull) /* NULL tupdatum */
+ {
+ if (cur->sk_flags & SK_ISNULL)
+ result = 0; /* NULL "=" NULL */
+ else if (cur->sk_flags & SK_BT_NULLS_FIRST)
+ result = -1; /* NULL "<" NOT_NULL */
+ else
+ result = 1; /* NULL ">" NOT_NULL */
+ }
+ else if (cur->sk_flags & SK_ISNULL) /* NOT_NULL tupdatum, NULL arrdatum */
+ {
+ if (cur->sk_flags & SK_BT_NULLS_FIRST)
+ result = 1; /* NOT_NULL ">" NULL */
+ else
+ result = -1; /* NOT_NULL "<" NULL */
+ }
+ else
+ {
+ /*
+ * Like _bt_compare, we need to be careful of cross-type comparisons,
+ * so the left value has to be the value that came from an index tuple
+ */
+ result = DatumGetInt32(FunctionCall2Coll(orderproc, cur->sk_collation,
+ tupdatum, arrdatum));
+
+ /*
+ * We flip the sign by following the obvious rule: flip whenever the
+ * column is a DESC column.
+ *
+ * _bt_compare does it the wrong way around (flip when *ASC*) in order
+ * to compensate for passing its orderproc arguments backwards. We
+ * don't need to play these games because we find it natural to pass
+ * tupdatum as the left value (and arrdatum as the right value).
+ */
+ if (cur->sk_flags & SK_BT_DESC)
+ INVERT_COMPARE_RESULT(result);
+ }
+
+ return result;
+}
+
+/*
+ * _bt_binsrch_array_skey() -- Binary search for next matching array key
+ *
+ * Returns an index to the first array element >= caller's tupdatum argument.
+ * This convention is more natural for forwards scan callers, but that can't
+ * really matter to backwards scan callers. Both callers require handling for
+ * the case where the match we return is < tupdatum, and symmetric handling
+ * for the case where our best match is > tupdatum.
+ *
+ * Also sets *set_elem_result to whatever _bt_compare_array_skey returned when
+ * we compared the returned array element to caller's tupdatum argument. This
+ * helps our caller to determine how advancing its array (to the element we'll
+ * return an offset to) might need to carry to higher order arrays.
+ *
+ * cur_elem_start indicates if the binary search should begin at the array's
+ * current element (or have the current element as an upper bound if it's a
+ * backward scan). It's safe for searches against required scan key arrays to
+ * reuse earlier search bounds like this because such arrays always advance in
+ * lockstep with the index scan's progress through the index's key space.
+ */
+static int
+_bt_binsrch_array_skey(FmgrInfo *orderproc,
+ bool cur_elem_start, ScanDirection dir,
+ Datum tupdatum, bool tupnull,
+ BTArrayKeyInfo *array, ScanKey cur,
+ int32 *set_elem_result)
+{
+ int low_elem,
+ mid_elem,
+ high_elem,
+ result = 0;
+
+ Assert(cur->sk_flags & SK_SEARCHARRAY);
+ Assert(cur->sk_strategy == BTEqualStrategyNumber);
+
+ low_elem = 0;
+ mid_elem = -1;
+ high_elem = array->num_elems - 1;
+ if (cur_elem_start)
+ {
+ if (ScanDirectionIsForward(dir))
+ low_elem = array->cur_elem;
+ else
+ high_elem = array->cur_elem;
+ }
+
+ while (high_elem > low_elem)
+ {
+ Datum arrdatum;
+
+ mid_elem = low_elem + ((high_elem - low_elem) / 2);
+ arrdatum = array->elem_values[mid_elem];
+
+ result = _bt_compare_array_skey(orderproc, tupdatum, tupnull,
+ arrdatum, cur);
+
+ if (result == 0)
+ {
+ /*
+ * Each array was deduplicated during initial preprocessing, so
+ * it's safe to quit as soon as we see an equal array element.
+ * This often saves an extra comparison or two...
+ */
+ low_elem = mid_elem;
+ break;
+ }
+
+ if (result > 0)
+ low_elem = mid_elem + 1;
+ else
+ high_elem = mid_elem;
+ }
+
+ /*
+ * ...but our caller also cares about how its searched-for tuple datum
+ * compares to the array element we'll return. Set *set_elem_result with
+ * the result of that comparison specifically.
+ */
+ if (low_elem != mid_elem)
+ result = _bt_compare_array_skey(orderproc, tupdatum, tupnull,
+ array->elem_values[low_elem], cur);
+
+ *set_elem_result = result;
+
+ return low_elem;
+}
+
/*
* _bt_start_array_keys() -- Initialize array keys at start of a scan
*
@@ -532,29 +870,40 @@ _bt_start_array_keys(IndexScanDesc scan, ScanDirection dir)
skey->sk_argument = curArrayKey->elem_values[curArrayKey->cur_elem];
}
- so->arraysStarted = true;
+ so->advanceDir = dir;
}
/*
- * _bt_advance_array_keys() -- Advance to next set of array elements
+ * _bt_advance_array_keys_increment() -- Advance to next set of array elements
+ *
+ * Advances the array keys by a single increment in the current scan
+ * direction. When there are multiple array keys this can roll over from the
+ * lowest order array to higher order arrays.
*
* Returns true if there is another set of values to consider, false if not.
* On true result, the scankeys are initialized with the next set of values.
+ * On false result, the scankeys stay the same, and the array keys are not
+ * advanced (every array remains at its final element for scan direction).
+ *
+ * Note: routine only initializes so->arrayKeyData[] scankeys. Caller must
+ * either call _bt_update_keys_with_arraykeys or call _bt_preprocess_keys to
+ * update the scan's search-type scankeys.
*/
-bool
-_bt_advance_array_keys(IndexScanDesc scan, ScanDirection dir)
+static bool
+_bt_advance_array_keys_increment(IndexScanDesc scan, ScanDirection dir)
{
BTScanOpaque so = (BTScanOpaque) scan->opaque;
bool found = false;
- int i;
+
+ Assert(!so->needPrimScan);
/*
* We must advance the last array key most quickly, since it will
* correspond to the lowest-order index column among the available
- * qualifications. This is necessary to ensure correct ordering of output
- * when there are multiple array keys.
+ * qualifications. Rolling over like this is necessary to ensure correct
+ * ordering of output when there are multiple array keys.
*/
- for (i = so->numArrayKeys - 1; i >= 0; i--)
+ for (int i = so->numArrayKeys - 1; i >= 0; i--)
{
BTArrayKeyInfo *curArrayKey = &so->arrayKeys[i];
ScanKey skey = &so->arrayKeyData[curArrayKey->scan_key];
@@ -588,85 +937,989 @@ _bt_advance_array_keys(IndexScanDesc scan, ScanDirection dir)
break;
}
- /* advance parallel scan */
- if (scan->parallel_scan != NULL)
- _bt_parallel_advance_array_keys(scan);
+ if (found)
+ return true;
/*
- * When no new array keys were found, the scan is "past the end" of the
- * array keys. _bt_start_array_keys can still "restart" the array keys if
- * a rescan is required.
+ * Don't allow the entire set of array keys to roll over: restore the
+ * array keys to the state they were in before we were called.
+ *
+ * This ensures that the array keys only ratchet forward (or backwards in
+ * the case of backward scans). Our "so->arrayKeyData[]" scan keys should
+ * always match the current "so->keyData[]" search-type scan keys (except
+ * for a brief moment during array key advancement).
*/
- if (!found)
- so->arraysStarted = false;
-
- return found;
-}
-
-/*
- * _bt_mark_array_keys() -- Handle array keys during btmarkpos
- *
- * Save the current state of the array keys as the "mark" position.
- */
-void
-_bt_mark_array_keys(IndexScanDesc scan)
-{
- BTScanOpaque so = (BTScanOpaque) scan->opaque;
- int i;
-
- for (i = 0; i < so->numArrayKeys; i++)
+ for (int i = 0; i < so->numArrayKeys; i++)
{
- BTArrayKeyInfo *curArrayKey = &so->arrayKeys[i];
+ BTArrayKeyInfo *rollarray = &so->arrayKeys[i];
+ ScanKey skey = &so->arrayKeyData[rollarray->scan_key];
- curArrayKey->mark_elem = curArrayKey->cur_elem;
+ if (ScanDirectionIsBackward(dir))
+ rollarray->cur_elem = 0;
+ else
+ rollarray->cur_elem = rollarray->num_elems - 1;
+ skey->sk_argument = rollarray->elem_values[rollarray->cur_elem];
}
+
+ return false;
}
/*
- * _bt_restore_array_keys() -- Handle array keys during btrestrpos
+ * _bt_rewind_array_keys() -- Handle array keys during btrestrpos
*
- * Restore the array keys to where they were when the mark was set.
+ * Restore the array keys to the start of the key space for the current scan
+ * direction.
*/
void
-_bt_restore_array_keys(IndexScanDesc scan)
+_bt_rewind_array_keys(IndexScanDesc scan)
{
BTScanOpaque so = (BTScanOpaque) scan->opaque;
bool changed = false;
- int i;
- /* Restore each array key to its position when the mark was set */
- for (i = 0; i < so->numArrayKeys; i++)
+ Assert(so->advanceDir != NoMovementScanDirection);
+
+ /*
+ * Restore each array key to its initial position for the current scan
+ * direction as of the last time the arrays advanced
+ */
+ for (int i = 0; i < so->numArrayKeys; i++)
{
BTArrayKeyInfo *curArrayKey = &so->arrayKeys[i];
ScanKey skey = &so->arrayKeyData[curArrayKey->scan_key];
- int mark_elem = curArrayKey->mark_elem;
+ int first_elem_dir;
- if (curArrayKey->cur_elem != mark_elem)
+ if (ScanDirectionIsForward(so->advanceDir))
+ first_elem_dir = 0;
+ else
+ first_elem_dir = curArrayKey->num_elems - 1;
+
+ if (curArrayKey->cur_elem != first_elem_dir)
{
- curArrayKey->cur_elem = mark_elem;
- skey->sk_argument = curArrayKey->elem_values[mark_elem];
+ curArrayKey->cur_elem = first_elem_dir;
+ skey->sk_argument = curArrayKey->elem_values[first_elem_dir];
changed = true;
}
}
+ if (changed)
+ _bt_update_keys_with_arraykeys(scan);
+
+ Assert(_bt_verify_keys_with_arraykeys(scan));
+
/*
- * If we changed any keys, we must redo _bt_preprocess_keys. That might
- * sound like overkill, but in cases with multiple keys per index column
- * it seems necessary to do the full set of pushups.
+ * Invert the scan direction as of the last time the array keys advanced.
*
- * Also do this whenever the scan's set of array keys "wrapped around" at
- * the end of the last primitive index scan. There won't have been a call
- * to _bt_preprocess_keys from some other place following wrap around, so
- * we do it for ourselves.
+ * This prevents _bt_steppage from fully trusting currPos.moreRight and
+ * currPos.moreLeft in cases where _bt_readpage/_bt_checkkeys don't get
+ * the opportunity to consider advancing the array keys as expected.
*/
- if (changed || !so->arraysStarted)
- {
- _bt_preprocess_keys(scan);
- /* The mark should have been set on a consistent set of keys... */
- Assert(so->qual_ok);
- }
+ if (ScanDirectionIsForward(so->advanceDir))
+ so->advanceDir = BackwardScanDirection;
+ else
+ so->advanceDir = ForwardScanDirection;
}
+/*
+ * _bt_tuple_before_array_skeys() -- _bt_checkkeys array helper function
+ *
+ * Routine to determine if a continuescan=false tuple (set that way by an
+ * initial call to _bt_check_compare) must advance the scan's array keys.
+ * Only call here when _bt_check_compare already set continuescan=false.
+ *
+ * Returns true when caller passes a tuple that is < the current set of array
+ * keys for the most significant non-equal column/scan key (or > for backwards
+ * scans). This means that it cannot possibly be time to advance the array
+ * keys just yet. _bt_checkkeys caller should suppress its _bt_check_compare
+ * call, and return -- the tuple is treated as not satisfying our indexquals.
+ *
+ * Returns false when caller's tuple is >= the current array keys (or <=, in
+ * the case of backwards scans). This means that it is now time for our
+ * caller to advance the array keys (unless caller broke the rules by not
+ * checking with _bt_check_compare before calling here).
+ *
+ * Note: advancing the array keys may be required when every attribute value
+ * from caller's tuple is equal to corresponding scan key/array datums. See
+ * _bt_advance_array_keys and its handling of inequalities for details.
+ *
+ * Note: caller passes _bt_check_compare-set sktrig value to indicate which
+ * scan key triggered the call. If this is for any scan key that isn't a
+ * required equality strategy scan key, calling here is a no-op, meaning that
+ * we'll invariably return false. We just accept whatever _bt_check_compare
+ * indicated about the scan when it involves a required inequality scan key.
+ * We never care about nonrequired scan keys, including equality strategy
+ * array scan keys (though _bt_check_compare can temporarily end the scan to
+ * advance their arrays in _bt_advance_array_keys, which we'll never prevent).
+ */
+static bool
+_bt_tuple_before_array_skeys(IndexScanDesc scan, BTReadPageState *pstate,
+ IndexTuple tuple, int sktrig, bool validtrig)
+{
+ BTScanOpaque so = (BTScanOpaque) scan->opaque;
+ Relation rel = scan->indexRelation;
+ ScanDirection dir = pstate->dir;
+ TupleDesc itupdesc = RelationGetDescr(rel);
+ ScanKey cur;
+ int ntupatts = BTreeTupleGetNAtts(tuple, rel),
+ ikey;
+
+ Assert(so->numArrayKeys > 0);
+ Assert(so->numberOfKeys > 0);
+ Assert(!so->needPrimScan);
+
+ for (cur = so->keyData + sktrig, ikey = sktrig;
+ ikey < so->numberOfKeys;
+ cur++, ikey++)
+ {
+ int attnum = cur->sk_attno;
+ FmgrInfo *orderproc;
+ Datum tupdatum;
+ bool tupnull;
+ int32 result;
+
+ /*
+ * Unlike _bt_check_compare and _bt_advance_array_keys, we never deal
+ * with inequality strategy scan keys (even those marked required). We
+ * also don't deal with non-required equality keys -- even when they
+ * happen to have arrays that might need to be advanced.
+ *
+ * Note: cannot "break" here due to corner cases involving redundant
+ * scan keys that weren't eliminated within _bt_preprocess_keys.
+ */
+ if (cur->sk_strategy != BTEqualStrategyNumber ||
+ (cur->sk_flags & SK_BT_REQFWD) == 0)
+ continue;
+
+ /* Required equality scan keys always required in both directions */
+ Assert((cur->sk_flags & SK_BT_REQFWD) &&
+ (cur->sk_flags & SK_BT_REQBKWD));
+
+ if (attnum > ntupatts)
+ {
+ Assert(!validtrig);
+
+ /*
+ * When we reach a high key's truncated attribute, assume that the
+ * tuple attribute's value is >= the scan's equality constraint
+ * scan keys, forcing another _bt_advance_array_keys call.
+ *
+ * You might wonder why we don't treat truncated attributes as
+ * having values < our equality constraints instead; we're not
+ * treating the truncated attributes as having -inf values here,
+ * which is how things are done in _bt_compare.
+ *
+ * We're often called during finaltup prechecks, where we help our
+ * caller to decide whether or not it should terminate the current
+ * primitive index scan. Our behavior here implements a policy of
+ * being slightly optimistic about what will be found on the next
+ * page when the current primitive scan continues onto that page.
+ * (This is also closest to what _bt_check_compare does.)
+ */
+ return false;
+ }
+
+ tupdatum = index_getattr(tuple, attnum, itupdesc, &tupnull);
+
+ orderproc = &so->orderProcs[attnum - 1];
+ result = _bt_compare_array_skey(orderproc, tupdatum, tupnull,
+ cur->sk_argument, cur);
+
+ /*
+ * Does this comparison indicate that caller must _not_ advance the
+ * scan's arrays just yet? (This implements the linear search process
+ * described in _bt_advance_array_keys.)
+ */
+ if ((ScanDirectionIsForward(dir) && result < 0) ||
+ (ScanDirectionIsBackward(dir) && result > 0))
+ return true;
+
+ /*
+ * Does this comparison indicate that caller should now advance the
+ * scan's arrays?
+ */
+ if (validtrig || result != 0)
+ {
+ Assert(result != 0);
+ return false;
+ }
+
+ /*
+ * Inconcusive -- need to check later scan keys, too.
+ *
+ * This must be a finaltup precheck, or perhaps a call made from an
+ * assertion.
+ */
+ Assert(result == 0);
+ Assert(!validtrig);
+ }
+
+ /*
+ * Default assumption is that caller must now advance the array keys.
+ *
+ * Note that we'll always end up here when sktrig corresponds to some
+ * non-required array type scan key that _bt_check_compare saw wasn't
+ * satisfied by caller's tuple.
+ */
+ return false;
+}
+
+/*
+ * _bt_array_keys_remain() -- start scheduled primitive index scan?
+ *
+ * Returns true if _bt_checkkeys scheduled another primitive index scan, just
+ * as the last one ended. Otherwise returns false, indicating that the array
+ * keys are now fully exhausted.
+ *
+ * Only call here during scans with one or more equality type array scan keys.
+ */
+bool
+_bt_array_keys_remain(IndexScanDesc scan, ScanDirection dir)
+{
+ BTScanOpaque so = (BTScanOpaque) scan->opaque;
+
+ Assert(so->numArrayKeys);
+ Assert(so->advanceDir == dir);
+
+ /*
+ * Array keys are advanced within _bt_checkkeys when the scan reaches the
+ * leaf level (more precisely, they're advanced when the scan reaches the
+ * end of each distinct set of array elements). This process avoids
+ * repeat access to leaf pages (across multiple primitive index scans) by
+ * advancing the scan's array keys when it allows the primitive index scan
+ * to find nearby matching tuples (or when it eliminates ranges of array
+ * key space that can't possibly be satisfied by any index tuple).
+ *
+ * _bt_checkkeys sets a simple flag variable to schedule another primitive
+ * index scan. This tells us what to do. We cannot rely on _bt_first
+ * always reaching _bt_checkkeys, though. There are various cases where
+ * that won't happen. For example, if the index is completely empty, then
+ * _bt_first won't get as far as calling _bt_readpage/_bt_checkkeys.
+ *
+ * We also don't expect _bt_checkkeys to be reached when searching for a
+ * non-existent value that happens to be higher than any existing value in
+ * the index. No _bt_checkkeys are expected when _bt_readpage reads the
+ * rightmost page during such a scan -- even a _bt_checkkeys call against
+ * the high key won't happen. There is an analogous issue for backwards
+ * scans that search for a value lower than all existing index tuples.
+ *
+ * We don't actually require special handling for these cases -- we don't
+ * need to be explicitly instructed to _not_ perform another primitive
+ * index scan. This is correct for all of the cases we've listed so far,
+ * which all involve primitive index scans that access pages "near the
+ * boundaries of the key space" (the leftmost page, the rightmost page, or
+ * an imaginary empty leaf root page). If _bt_checkkeys cannot be reached
+ * by a primitive index scan for one set of array keys, it follows that it
+ * also won't be reached for any later set of array keys...
+ */
+ if (!so->qual_ok)
+ {
+ /*
+ * ...though there is one exception: _bt_first's _bt_preprocess_keys
+ * call can determine that the scan's input scan keys can never be
+ * satisfied. That might be true for one set of array keys, but not
+ * the next set.
+ *
+ * Handle this by advancing the array keys incrementally ourselves.
+ * When this succeeds, start another primitive index scan.
+ */
+ CHECK_FOR_INTERRUPTS();
+
+ Assert(!so->needPrimScan);
+ if (_bt_advance_array_keys_increment(scan, dir))
+ return true;
+
+ /* Array keys are now exhausted */
+ }
+
+ /*
+ * Has another primitive index scan been scheduled by _bt_checkkeys?
+ */
+ if (so->needPrimScan)
+ {
+ /* Yes -- tell caller to call _bt_first once again */
+ so->needPrimScan = false;
+ if (scan->parallel_scan != NULL)
+ _bt_parallel_next_primitive_scan(scan);
+
+ return true;
+ }
+
+ /*
+ * No more primitive index scans. Terminate the top-level scan.
+ */
+ if (scan->parallel_scan != NULL)
+ _bt_parallel_done(scan);
+
+ return false;
+}
+
+/*
+ * _bt_advance_array_keys() -- Advance array elements using a tuple
+ *
+ * Like _bt_check_compare, our return value indicates if tuple satisfied the
+ * qual (specifically our new qual). There must be a new qual whenever we're
+ * called (unless the top-level scan terminates). After we return, all later
+ * calls to _bt_check_compare will also use the same new qual (a qual with the
+ * newly advanced array key values that were set here by us).
+ *
+ * We'll also set pstate.continuescan for caller. When this is set to false,
+ * it usually just ends the ongoing primitive index scan (we'll have scheduled
+ * another one in passing). But when all required array keys were exhausted,
+ * setting pstate.continuescan=false here ends the top-level index scan (since
+ * no new primitive scan will have been scheduled). Most calls here will have
+ * us set pstate.continuescan=true, which just indicates that the scan should
+ * proceed onto the next tuple (just like when _bt_check_compare does it).
+ *
+ * _bt_tuple_before_array_skeys is responsible for determining if the current
+ * place in the scan is >= the current array keys. Calling here before that
+ * point will prematurely advance the array keys, leading to wrong query
+ * results.
+ *
+ * We're responsible for ensuring that caller's tuple is <= current/newly
+ * advanced required array keys once we return. We try to find an exact
+ * match, but failing that we'll advance the array keys to whatever set of
+ * array elements comes next in the key space for the current scan direction.
+ * Required array keys "ratchet forwards". They can only advance as the scan
+ * itself advances through the index/key space.
+ *
+ * (The invariants are the same for backwards scans, except that the operators
+ * are flipped: just replace the precondition's >= operator with a <=, and the
+ * postcondition's <= operator with with a >=. In other words, just swap the
+ * precondition with the postcondition.)
+ *
+ * We also deal with "advancing" non-required arrays here. Sometimes that'll
+ * be the sole reason for calling here. These calls are the only exception to
+ * the general rule about always advancing required array keys (since they're
+ * the only case where we simply don't need to touch any required array, which
+ * must already be satisfied by caller's tuple). Calls triggered by any scan
+ * key that's required in the current scan direction are strictly guaranteed
+ * to advance the required array keys (or end the top-level scan), though.
+ *
+ * Note that we deal with all required equality strategy scan keys here; it's
+ * not limited to array scan keys. They're equality constraints for our
+ * purposes, and so are handled as degenerate single element arrays here.
+ * Obviously, they can never really advance in the way that real arrays can,
+ * but they must still affect how we advance real array scan keys, just like
+ * any other equality constraint. We have to keep around a 3-way ORDER proc
+ * for these (just using the "=" operator won't do), since in general whether
+ * the tuple is < or > some non-array equality key might influence advancement
+ * of any of the scan's actual arrays. The top-level scan can only terminate
+ * after it has processed the key space covered by the product of each and
+ * every equality constraint, including both non-arrays and (required) arrays.
+ *
+ * Note also that we may sometimes need to advance the array keys when the
+ * existing array keys are already an exact match for every corresponding
+ * value from caller's tuple according to _bt_check_compare. This is how we
+ * deal with inequalities that are required in the current scan direction.
+ * They can advance the array keys here, even though they don't influence the
+ * initial positioning strategy within _bt_first (only inequalities required
+ * in the _opposite_ direction to the scan influence _bt_first in this way).
+ *
+ * As discussed already, we guarantee that the array keys will either be
+ * advanced such that caller's tuple is <= the new array keys in respect of
+ * required array keys (plus any other required equality strategy scan keys)
+ * when we return (unless the arrays are totally exhausted instead). The real
+ * guarantee is actually slightly stronger than that, though it only matters
+ * to scans that have required inequality strategy scan keys. The precise
+ * promise we make is that the array keys will always advance to the maximum
+ * possible extent that we can know to be safe based on caller's tuple alone.
+ * Note that it's just about possible that every required equality strategy
+ * scan key will be satisfied (or could be satisfied by advancing the array
+ * keys), yet we might advance the array keys _beyond_ our exactly-matching
+ * element values due to a still-unsatisfied inequality strategy scan key.
+ */
+static bool
+_bt_advance_array_keys(IndexScanDesc scan, BTReadPageState *pstate,
+ IndexTuple tuple, int sktrig)
+{
+ BTScanOpaque so = (BTScanOpaque) scan->opaque;
+ Relation rel = scan->indexRelation;
+ ScanDirection dir = pstate->dir;
+ TupleDesc itupdesc = RelationGetDescr(rel);
+ ScanKey cur;
+ int ikey,
+ arrayidx = 0,
+ ntupatts = BTreeTupleGetNAtts(tuple, rel);
+ bool arrays_advanced = false,
+ arrays_exhausted,
+ sktrigrequired = false,
+ beyond_end_advance = false,
+ foundRequiredOppositeDirOnly = false,
+ all_arraylike_sk_satisfied = true,
+ all_required_sk_satisfied = true;
+
+ Assert(_bt_verify_keys_with_arraykeys(scan));
+
+ /*
+ * Iterate through the scan's search-type scankeys (so->keyData[]), and
+ * set input scan keys (so->arrayKeyData[]) to new array values
+ */
+ for (cur = so->keyData, ikey = 0; ikey < so->numberOfKeys; cur++, ikey++)
+ {
+ BTArrayKeyInfo *array = NULL;
+ ScanKey skeyarray = NULL;
+ FmgrInfo *orderproc;
+ int attnum = cur->sk_attno;
+ Datum tupdatum;
+ bool requiredSameDir = false,
+ requiredOppositeDirOnly = false,
+ tupnull;
+ int32 result;
+ int set_elem = 0;
+
+ /*
+ * Set up ORDER 3-way comparison function and array state
+ */
+ orderproc = &so->orderProcs[attnum - 1];
+ if (cur->sk_flags & SK_SEARCHARRAY &&
+ cur->sk_strategy == BTEqualStrategyNumber)
+ {
+ Assert(arrayidx < so->numArrayKeys);
+ array = &so->arrayKeys[arrayidx++];
+ skeyarray = &so->arrayKeyData[array->scan_key];
+ Assert(skeyarray->sk_attno == attnum);
+ }
+
+ if (((cur->sk_flags & SK_BT_REQFWD) && ScanDirectionIsForward(dir)) ||
+ ((cur->sk_flags & SK_BT_REQBKWD) && ScanDirectionIsBackward(dir)))
+ requiredSameDir = true;
+ else if (((cur->sk_flags & SK_BT_REQFWD) && ScanDirectionIsBackward(dir)) ||
+ ((cur->sk_flags & SK_BT_REQBKWD) && ScanDirectionIsForward(dir)))
+ requiredOppositeDirOnly = true;
+
+ /*
+ * Optimization: Skip over known-satisfied scan keys
+ */
+ if (ikey < sktrig)
+ continue;
+ if (ikey == sktrig)
+ sktrigrequired = requiredSameDir;
+
+ /*
+ * When we come across an inequality scan key that's required in the
+ * opposite direction only, and that might affect where our scan ends,
+ * remember it. We'll only need this information when all prior
+ * equality constraints are satisfied.
+ */
+ if (requiredOppositeDirOnly && sktrigrequired &&
+ all_arraylike_sk_satisfied)
+ {
+ Assert(cur->sk_strategy != BTEqualStrategyNumber);
+ Assert(all_required_sk_satisfied);
+ Assert(!foundRequiredOppositeDirOnly);
+
+ foundRequiredOppositeDirOnly = true;
+
+ continue;
+ }
+
+ /*
+ * Other than that, we're not interested in scan keys that aren't
+ * required in the current scan direction (unless they're non-required
+ * array equality scan keys, which still need to be advanced by us)
+ */
+ if (!requiredSameDir && !array)
+ continue;
+
+ /*
+ * Handle a required non-array scan key that the initial call to
+ * _bt_check_compare indicated triggered array advancement, if any.
+ *
+ * The non-array scan key's strategy will be <, <=, or = during a
+ * forwards scan (or any one of =, >=, or > during a backwards scan).
+ * It follows that the corresponding tuple attribute's value must now
+ * be either > or >= the scan key value (for backwards scans it must
+ * be either < or <= that value).
+ *
+ * If this is a required equality strategy scan key, this is just an
+ * optimization; _bt_tuple_before_array_skeys already confirmed that
+ * this scan key places us ahead of caller's tuple. There's no need
+ * to repeat that work now. (We only do comparisons of any required
+ * non-array equality scan keys that come after the triggering key.)
+ *
+ * If this is a required inequality strategy scan key, we _must_ rely
+ * on _bt_check_compare like this; it knows all the intricacies around
+ * evaluating inequality strategy scan keys (e.g., row comparisons).
+ * There is no simple mapping onto the opclass ORDER proc we can use.
+ * But once we know that we have an unsatisfied inequality, we can
+ * treat it in the same way as an unsatisfied equality at this point.
+ * (We don't need to worry about later required inequalities, since
+ * there can't be any after the first one. While it's possible that
+ * _bt_preprocess_keys failed to determine which of several "required"
+ * scan keys for this same attribute and same scan direction are truly
+ * required, that changes nothing, really. Even in this corner case,
+ * we can safely assume that any other "required" inequality that is
+ * still satisfied must have been redundant all along.)
+ *
+ * The arrays advance correctly in both cases because both involve the
+ * scan reaching the end of the key space for a higher order array key
+ * (or some distinct set of higher-order array keys, taken together).
+ * The only real difference is that in the equality case the end is
+ * "strictly at the end of an array key", whereas in the inequality
+ * case it's "within an array key". Either way we'll increment higher
+ * order arrays by one increment (the next-highest array might need to
+ * roll over to the next-next highest array in turn, and so on).
+ *
+ * See below for a full explanation of "beyond end" advancement.
+ */
+ if (ikey == sktrig && !array)
+ {
+ Assert(requiredSameDir);
+ Assert(!arrays_advanced);
+
+ beyond_end_advance = true;
+ all_arraylike_sk_satisfied = all_required_sk_satisfied = false;
+
+ continue;
+ }
+
+ /*
+ * Nothing for us to do with a required inequality strategy scan key
+ * that wasn't the one that _bt_check_compare stopped on
+ */
+ if (cur->sk_strategy != BTEqualStrategyNumber)
+ continue;
+
+ /*
+ * Here we perform steps for all array scan keys after a required
+ * array scan key whose binary search triggered "beyond end of array
+ * element" array advancement due to encountering a tuple attribute
+ * value > the closest matching array key (or < for backwards scans).
+ *
+ * See below for a full explanation of "beyond end" advancement.
+ *
+ * NB: We must do this for all arrays -- not just required arrays.
+ * Otherwise the incremental array advancement step won't "carry".
+ */
+ if (beyond_end_advance)
+ {
+ int final_elem_dir;
+
+ if (ScanDirectionIsBackward(dir) || !array)
+ final_elem_dir = 0;
+ else
+ final_elem_dir = array->num_elems - 1;
+
+ if (array && array->cur_elem != final_elem_dir)
+ {
+ array->cur_elem = final_elem_dir;
+ skeyarray->sk_argument = array->elem_values[final_elem_dir];
+ arrays_advanced = true;
+ }
+
+ continue;
+ }
+
+ /*
+ * Here we perform steps for any required scan keys after the first
+ * required scan key whose tuple attribute was < the closest matching
+ * array key when we dealt with it (or > for backwards scans).
+ *
+ * This earlier required array key already puts us ahead of caller's
+ * tuple in the key space (for the current scan direction). We must
+ * make sure that subsequent lower-order array keys do not put us too
+ * far ahead (ahead of tuples that have yet to be seen by our caller).
+ * For example, when a tuple "(a, b) = (42, 5)" advances the array
+ * keys on "a" from 40 to 45, we must also set "b" to whatever the
+ * first array element for "b" is. It would be wrong to allow "b" to
+ * be set based on the tuple value.
+ *
+ * Perform the same steps with truncated high key attributes. You can
+ * think of this as a "binary search" for the element closest to the
+ * value -inf. Again, the arrays must never get ahead of the scan.
+ */
+ if (!all_arraylike_sk_satisfied || attnum > ntupatts)
+ {
+ int first_elem_dir;
+
+ if (ScanDirectionIsForward(dir) || !array)
+ first_elem_dir = 0;
+ else
+ first_elem_dir = array->num_elems - 1;
+
+ if (array && array->cur_elem != first_elem_dir)
+ {
+ array->cur_elem = first_elem_dir;
+ skeyarray->sk_argument = array->elem_values[first_elem_dir];
+ arrays_advanced = true;
+ }
+
+ /*
+ * Truncated -inf value will always be assumed to satisfy any
+ * required equality scan keys according to _bt_check_compare.
+ * This avoids a later _bt_check_compare recheck.
+ *
+ * Deliberately don't unset all_required_sk_satisfied here. This
+ * follows _bt_tuple_before_array_skeys's example. We don't want
+ * to treat -inf as a non-match when making a final decision on
+ * whether to move to the next page. This implements a policy of
+ * being optimistic about finding real matches for lower-order
+ * required attributes that are truncated to -inf in finaltup.
+ */
+ all_arraylike_sk_satisfied = false;
+
+ continue;
+ }
+
+ /*
+ * Search in scankey's array for the corresponding tuple attribute
+ * value from caller's tuple
+ */
+ tupdatum = index_getattr(tuple, attnum, itupdesc, &tupnull);
+
+ if (array)
+ {
+ bool ratchets = (requiredSameDir && !arrays_advanced);
+
+ /*
+ * Binary search for closest match that's available from the array
+ */
+ set_elem = _bt_binsrch_array_skey(orderproc, ratchets, dir,
+ tupdatum, tupnull,
+ array, cur, &result);
+
+ /*
+ * Required arrays only ever ratchet forwards (backwards).
+ *
+ * This condition makes it safe for binary searches to skip over
+ * array elements that the scan must already be ahead of by now.
+ * That is strictly an optimization. Our assertion verifies that
+ * the condition holds, which doesn't depend on the optimization.
+ */
+ Assert(!ratchets ||
+ ((ScanDirectionIsForward(dir) && set_elem >= array->cur_elem) ||
+ (ScanDirectionIsBackward(dir) && set_elem <= array->cur_elem)));
+ Assert(set_elem >= 0 && set_elem < array->num_elems);
+ }
+ else
+ {
+ Assert(requiredSameDir);
+
+ /*
+ * This is a required non-array equality strategy scan key, which
+ * we'll treat as a degenerate single value array.
+ *
+ * We really do need an ORDER proc for this (we can't just rely on
+ * the scan key's equality operator). We need to know whether the
+ * tuple as a whole is either behind or ahead of (or covered by)
+ * the key space represented by our required arrays as a group.
+ *
+ * This scan key's imaginary "array" can't really advance, but it
+ * can still roll over like any other array. (Actually, this is
+ * no different to real single value arrays, which never advance
+ * without rolling over -- they can never truly advance, either.)
+ */
+ result = _bt_compare_array_skey(orderproc, tupdatum, tupnull,
+ cur->sk_argument, cur);
+ }
+
+ /*
+ * Consider "beyond end of array element" array advancement.
+ *
+ * When the tuple attribute value is > the closest matching array key
+ * (or < in the backwards scan case), we need to ratchet this array
+ * forward (backward) by one increment, so that caller's tuple ends up
+ * being < final array value instead (or > final array value instead).
+ * This process has to work for all of the arrays, not just this one:
+ * it must "carry" to higher-order arrays when the set_elem that we
+ * just found happens to be the final one for the scan's direction.
+ * Incrementing (decrementing) set_elem itself isn't good enough.
+ *
+ * Our approach is to provisionally use set_elem as if it was an exact
+ * match now, then set each later/less significant array to whatever
+ * its final element is. Once outside the loop we'll then "increment
+ * this array's set_elem" by calling _bt_advance_array_keys_increment.
+ * That way the process rolls over to higher order arrays as needed.
+ *
+ * Under this scheme any required arrays only ever ratchet forwards
+ * (or backwards), and always do so to the maximum possible extent
+ * that we can know will be safe without seeing the scan's next tuple.
+ * We don't need any special handling of required equality scan keys
+ * that lack a real array for us to advance, either. It also won't
+ * matter if all of the scan's real arrays are non-required arrays.
+ */
+ if (requiredSameDir &&
+ ((ScanDirectionIsForward(dir) && result > 0) ||
+ (ScanDirectionIsBackward(dir) && result < 0)))
+ beyond_end_advance = true;
+
+ /*
+ * Also track whether all relevant attributes from caller's tuple will
+ * be equal to the scan's array keys once we're done with it
+ */
+ if (result != 0)
+ {
+ all_arraylike_sk_satisfied = false;
+ if (requiredSameDir)
+ all_required_sk_satisfied = false;
+ }
+
+ /*
+ * Optimization: If this call was triggered by a non-required array,
+ * and we know that tuple won't satisfy the qual, we give up right
+ * away. This often avoids advancing the array keys, which will save
+ * wasted cycles from calling _bt_update_keys_with_arraykeys below.
+ */
+ if (!all_arraylike_sk_satisfied && !sktrigrequired)
+ {
+ Assert(!requiredSameDir && !foundRequiredOppositeDirOnly);
+ Assert(!beyond_end_advance);
+
+ break;
+ }
+
+ /* Advance array keys, even if set_elem isn't an exact match */
+ if (array && array->cur_elem != set_elem)
+ {
+ array->cur_elem = set_elem;
+ skeyarray->sk_argument = array->elem_values[set_elem];
+ arrays_advanced = true;
+ }
+ }
+
+ /*
+ * Consider if we need to advance the array keys incrementally to finish
+ * off "beyond end of array element" array advancement. This is the only
+ * way that the array keys can be exhausted, which is the only way that
+ * the top-level index scan can be terminated here by us.
+ */
+ arrays_exhausted = false;
+ if (beyond_end_advance)
+ {
+ /* Non-required scan keys never exhaust arrays/end top-level scan */
+ Assert(sktrigrequired && !all_required_sk_satisfied);
+
+ if (!_bt_advance_array_keys_increment(scan, dir))
+ arrays_exhausted = true;
+ else
+ arrays_advanced = true;
+ }
+
+ if (arrays_advanced)
+ {
+ /*
+ * We advanced the array keys. Finalize everything by performing an
+ * in-place update of the scan's search-type scan keys.
+ *
+ * If we missed this final step then any call to _bt_check_compare
+ * would use stale array keys until such time as _bt_preprocess_keys
+ * was once again called by _bt_first.
+ */
+ _bt_update_keys_with_arraykeys(scan);
+ so->advanceDir = dir;
+
+ /*
+ * If any required array keys were advanced, be prepared to recheck
+ * the final tuple against the new array keys (as an optimization)
+ */
+ if (sktrigrequired)
+ pstate->finaltupchecked = false;
+ }
+
+ /*
+ * If the array keys are now exhausted, end the top-level index scan
+ */
+ Assert(!so->needPrimScan);
+ Assert(_bt_verify_keys_with_arraykeys(scan));
+ if (arrays_exhausted)
+ {
+ Assert(sktrigrequired && !all_required_sk_satisfied);
+
+ pstate->continuescan = false;
+
+ /* Caller's tuple can't match new qual (if any), either */
+ return false;
+ }
+
+ /*
+ * Postcondition assertions (see header comments for a full explanation).
+ *
+ * Tuple must now be <= current/newly advanced required array keys. Same
+ * goes for other required equality type scan keys, which are "degenerate
+ * single value arrays" for our purposes. (As usual the rule is the same
+ * for backwards scans once the operators are flipped around.)
+ *
+ * Every call here is guaranteed to advance (or exhaust) all required
+ * arrays, with the sole exception of calls _bt_check_compare triggers
+ * when it encounters an unsatisfied non-required array scan key.
+ */
+ Assert(_bt_tuple_before_array_skeys(scan, pstate, tuple, 0, false) ==
+ !all_required_sk_satisfied);
+ Assert(arrays_advanced || !sktrigrequired);
+ Assert(sktrigrequired || all_required_sk_satisfied);
+
+ /*
+ * The array keys aren't exhausted, so provisionally assume that the
+ * current primitive index scan will continue
+ */
+ pstate->continuescan = true;
+
+ /*
+ * Does caller's tuple now match the new qual? Call _bt_check_compare a
+ * second time to find out (unless it's already clear that it can't).
+ */
+ if (all_arraylike_sk_satisfied && arrays_advanced)
+ {
+ bool continuescan;
+ int insktrig = sktrig + 1;
+
+ if (likely(_bt_check_compare(dir, so, tuple, ntupatts, itupdesc,
+ so->numArrayKeys, &continuescan,
+ &insktrig, false)))
+ return true;
+
+ /*
+ * Handle inequalities marked required in the current scan direction.
+ *
+ * It's just about possible that our _bt_check_compare call indicates
+ * that the scan should be terminated due to an unsatisfied inequality
+ * that wasn't initially recognized as such by us. Handle this by
+ * calling ourselves recursively while indicating that the trigger is
+ * now the inequality that we missed first time around.
+ *
+ * Note: we only need to do this in cases where the initial call to
+ * _bt_check_compare (that led to calling here) gave up upon finding
+ * an unsatisfied required equality/array scan key before it could
+ * reach the inequality. The second _bt_check_compare call took place
+ * after the array keys were advanced (to array keys that definitely
+ * match the tuple), so it can't have been overlooked a second time.
+ *
+ * Note: this is useful because we won't have to wait until the next
+ * tuple to advance the array keys a second time (to values that'll
+ * put the scan ahead of this tuple). Handling this ourselves isn't
+ * truly required. But it avoids complicating our contract. The only
+ * alternative is to allow an awkward exception to the general rule
+ * (the rule about always advancing the arrays to the maximum possible
+ * extent that caller's tuple can safely allow).
+ */
+ if (!continuescan)
+ {
+ ScanKey inequal PG_USED_FOR_ASSERTS_ONLY = so->keyData + insktrig;
+
+ Assert(sktrigrequired && all_required_sk_satisfied);
+ Assert(inequal->sk_strategy != BTEqualStrategyNumber);
+ Assert(((inequal->sk_flags & SK_BT_REQFWD) &&
+ ScanDirectionIsForward(dir)) ||
+ ((inequal->sk_flags & SK_BT_REQBKWD) &&
+ ScanDirectionIsBackward(dir)));
+
+ return _bt_advance_array_keys(scan, pstate, tuple, insktrig);
+ }
+ }
+
+ /*
+ * Handle inequalities marked required in the opposite scan direction.
+ *
+ * If we advanced the array keys (which is now certain except in the case
+ * where we only needed to deal with non-required arrays), it's possible
+ * that the scan is now at the start of "matching" tuples (at least by the
+ * definition used by _bt_tuple_before_array_skeys), but is nevertheless
+ * still many leaf pages before the position that _bt_first is capable of
+ * repositioning the scan to.
+ *
+ * This can happen when we have an inequality scan key required in the
+ * opposite direction only, that's less significant than the scan key that
+ * triggered array advancement during our initial _bt_check_compare call.
+ * If even finaltup doesn't satisfy this less significant inequality scan
+ * key once we temporarily flip the scan direction, that indicates that
+ * even finaltup is before the _bt_first-wise initial position for these
+ * newly advanced array keys.
+ */
+ if (all_required_sk_satisfied && foundRequiredOppositeDirOnly &&
+ pstate->finaltup)
+ {
+ int nfinaltupatts = BTreeTupleGetNAtts(pstate->finaltup, rel);
+ ScanDirection flipped = -dir;
+ bool continuescan;
+ int opsktrig = 0;
+
+ Assert(sktrigrequired && arrays_advanced);
+
+ _bt_check_compare(flipped, so, pstate->finaltup, nfinaltupatts,
+ itupdesc, so->numArrayKeys, &continuescan,
+ &opsktrig, false);
+
+ if (!continuescan && opsktrig > sktrig)
+ {
+ ScanKey inequal = so->keyData + opsktrig;
+
+ if (((inequal->sk_flags & SK_BT_REQFWD) &&
+ ScanDirectionIsForward(flipped)) ||
+ ((inequal->sk_flags & SK_BT_REQBKWD) &&
+ ScanDirectionIsBackward(flipped)))
+ {
+ Assert(inequal->sk_strategy != BTEqualStrategyNumber);
+
+ /*
+ * Continuing the ongoing primitive index scan as-is risks
+ * uselessly scanning a huge number of leaf pages from before
+ * the page that we'll quickly jump to by descending the index
+ * anew.
+ *
+ * Play it safe: start a new primitive index scan. _bt_first
+ * is guaranteed to at least move the scan to the next leaf
+ * page.
+ */
+ pstate->continuescan = false;
+ so->needPrimScan = true;
+
+ return false;
+ }
+ }
+
+ /*
+ * Caller's tuple might still be before the _bt_first-wise start of
+ * matches for the new array keys, but at least finaltup is at or
+ * ahead of that position. That's good enough; continue as-is.
+ */
+ }
+
+ /*
+ * Caller's tuple is < the newly advanced array keys (or > when this is a
+ * backwards scan).
+ *
+ * It's possible that later tuples will also turn out to have values that
+ * are still < the now-current array keys (or > the current array keys).
+ * Our caller will handle this by performing what amounts to a linear
+ * search of the page, implemented by calling _bt_check_compare and then
+ * _bt_tuple_before_array_skeys for each tuple. Our caller should locate
+ * the first tuple >= the array keys before long (or locate the first
+ * tuple <= the array keys before long).
+ *
+ * This approach has various advantages over a binary search of the page.
+ * We expect that our caller will either quickly discover the next tuple
+ * covered by the current array keys, or quickly discover that it needs
+ * another primitive index scan (using its finaltup precheck) instead.
+ * Either way, a binary search is unlikely to beat a simple linear search.
+ *
+ * It's also not clear that a binary search will be any faster when we
+ * really do have to search through hundreds of tuples beyond this one.
+ * Several binary searches (one per array advancement) might be required
+ * while reading through a single page. Our linear search is structured
+ * as one continuous search that just advances the arrays in passing, and
+ * that only needs a little extra logic to deal with inequality scan keys.
+ */
+ if (!all_required_sk_satisfied && tuple == pstate->finaltup)
+ {
+ /*
+ * There is one exception: when the page's final tuple advances the
+ * array keys without exactly matching keys for any required arrays,
+ * start a new primitive index scan -- don't let our caller continue
+ * to the next leaf page.
+ *
+ * In the forward scan case, finaltup is the page high key. We don't
+ * insist on having an exact match for truncated -inf attributes.
+ * They're never exactly equal to any real array key, but it makes
+ * sense to be optimistic about finding matches on the next page.
+ */
+ Assert(sktrigrequired && arrays_advanced);
+
+ pstate->continuescan = false;
+ so->needPrimScan = true;
+ }
+
+ /* In any case, this indextuple doesn't match the qual */
+ return false;
+}
/*
* _bt_preprocess_keys() -- Preprocess scan keys
@@ -741,6 +1994,19 @@ _bt_restore_array_keys(IndexScanDesc scan)
* Again, missing cross-type operators might cause us to fail to prove the
* quals contradictory when they really are, but the scan will work correctly.
*
+ * Index scans with array keys need to be able to advance each array's keys
+ * and make them the current search-type scan keys without calling here. They
+ * expect to be able to call _bt_update_keys_with_arraykeys instead. We need
+ * to be careful about that case when we determine redundancy; equality quals
+ * must not be eliminated as redundant on the basis of array input keys that
+ * might change before another call here can take place.
+ *
+ * Note, however, that the presence of an array scan key doesn't affect how we
+ * determine if index quals are contradictory. Contradictory qual scans move
+ * on to the next primitive index scan right away, by incrementing the scan's
+ * array keys once control reaches _bt_array_keys_remain. There won't be a
+ * call to _bt_update_keys_with_arraykeys, so there's nothing for us to break.
+ *
* Row comparison keys are currently also treated without any smarts:
* we just transfer them into the preprocessed array without any
* editorialization. We can treat them the same as an ordinary inequality
@@ -887,8 +2153,11 @@ _bt_preprocess_keys(IndexScanDesc scan)
so->qual_ok = false;
return;
}
- /* else discard the redundant non-equality key */
- xform[j] = NULL;
+ else if (!(eq->sk_flags & SK_SEARCHARRAY))
+ {
+ /* else discard the redundant non-equality key */
+ xform[j] = NULL;
+ }
}
/* else, cannot determine redundancy, keep both keys */
}
@@ -978,6 +2247,22 @@ _bt_preprocess_keys(IndexScanDesc scan)
continue;
}
+ /*
+ * Is this an array scan key that _bt_preprocess_array_keys merged
+ * with some earlier array key during its initial preprocessing pass?
+ */
+ if (cur->sk_flags & SK_BT_RDDNARRAY)
+ {
+ /*
+ * key is redundant for this primitive index scan (and will be
+ * redundant during all subsequent primitive index scans)
+ */
+ Assert(cur->sk_flags & SK_SEARCHARRAY);
+ Assert(j == (BTEqualStrategyNumber - 1));
+ Assert(so->numArrayKeys > 0);
+ continue;
+ }
+
/* have we seen one of these before? */
if (xform[j] == NULL)
{
@@ -991,7 +2276,26 @@ _bt_preprocess_keys(IndexScanDesc scan)
&test_result))
{
if (test_result)
- xform[j] = cur;
+ {
+ if (j == (BTEqualStrategyNumber - 1) &&
+ ((xform[j]->sk_flags & SK_SEARCHARRAY) ||
+ (cur->sk_flags & SK_SEARCHARRAY)))
+ {
+ /*
+ * Must never replace an = array operator ourselves,
+ * nor can we ever fail to remember an = array
+ * operator. _bt_update_keys_with_arraykeys expects
+ * this.
+ */
+ ScanKey outkey = &outkeys[new_numberOfKeys++];
+
+ memcpy(outkey, cur, sizeof(ScanKeyData));
+ if (numberOfEqualCols == attno - 1)
+ _bt_mark_scankey_required(outkey);
+ }
+ else
+ xform[j] = cur;
+ }
else if (j == (BTEqualStrategyNumber - 1))
{
/* key == a && key == b, but a != b */
@@ -1019,6 +2323,95 @@ _bt_preprocess_keys(IndexScanDesc scan)
so->numberOfKeys = new_numberOfKeys;
}
+/*
+ * _bt_update_keys_with_arraykeys() -- Finalize advancing array keys
+ *
+ * Transfers newly advanced array keys that were set in "so->arrayKeyData[]"
+ * over to corresponding "so->keyData[]" scan keys. Reuses most of the work
+ * that took place within _bt_preprocess_keys, only changing the array keys.
+ *
+ * It's safe to call here while holding a buffer lock, which isn't something
+ * that _bt_preprocess_keys can guarantee.
+ */
+static void
+_bt_update_keys_with_arraykeys(IndexScanDesc scan)
+{
+ BTScanOpaque so = (BTScanOpaque) scan->opaque;
+ ScanKey cur;
+ int ikey,
+ arrayidx = 0;
+
+ Assert(so->qual_ok);
+
+ for (cur = so->keyData, ikey = 0; ikey < so->numberOfKeys; cur++, ikey++)
+ {
+ BTArrayKeyInfo *array;
+ ScanKey skeyarray;
+
+ Assert((cur->sk_flags & SK_BT_RDDNARRAY) == 0);
+
+ /* Just update equality array scan keys */
+ if (cur->sk_strategy != BTEqualStrategyNumber ||
+ !(cur->sk_flags & SK_SEARCHARRAY))
+ continue;
+
+ array = &so->arrayKeys[arrayidx++];
+ skeyarray = &so->arrayKeyData[array->scan_key];
+
+ /* Update the scan key's argument */
+ Assert(cur->sk_attno == skeyarray->sk_attno);
+ cur->sk_argument = skeyarray->sk_argument;
+ }
+
+ Assert(arrayidx == so->numArrayKeys);
+}
+
+/*
+ * Verify that the scan's "so->arrayKeyData[]" scan keys are in agreement with
+ * the current "so->keyData[]" search-type scan keys. Used within assertions.
+ */
+#ifdef USE_ASSERT_CHECKING
+static bool
+_bt_verify_keys_with_arraykeys(IndexScanDesc scan)
+{
+ BTScanOpaque so = (BTScanOpaque) scan->opaque;
+ ScanKey cur;
+ int ikey,
+ arrayidx = 0;
+
+ if (!so->qual_ok)
+ return false;
+
+ for (cur = so->keyData, ikey = 0; ikey < so->numberOfKeys; cur++, ikey++)
+ {
+ BTArrayKeyInfo *array;
+ ScanKey skeyarray;
+
+ if (cur->sk_strategy != BTEqualStrategyNumber ||
+ !(cur->sk_flags & SK_SEARCHARRAY))
+ continue;
+
+ array = &so->arrayKeys[arrayidx++];
+ skeyarray = &so->arrayKeyData[array->scan_key];
+
+ /* Verify so->arrayKeyData[] input key has expected sk_argument */
+ if (skeyarray->sk_argument != array->elem_values[array->cur_elem])
+ return false;
+
+ /* Verify so->arrayKeyData[] input key agrees with output key */
+ if (cur->sk_attno != skeyarray->sk_attno)
+ return false;
+ if (cur->sk_argument != skeyarray->sk_argument)
+ return false;
+ }
+
+ if (arrayidx != so->numArrayKeys)
+ return false;
+
+ return true;
+}
+#endif
+
/*
* Compare two scankey values using a specified operator.
*
@@ -1352,58 +2745,210 @@ _bt_mark_scankey_required(ScanKey skey)
*
* Return true if so, false if not. If the tuple fails to pass the qual,
* we also determine whether there's any need to continue the scan beyond
- * this tuple, and set *continuescan accordingly. See comments for
+ * this tuple, and set pstate.continuescan accordingly. See comments for
* _bt_preprocess_keys(), above, about how this is done.
*
- * Forward scan callers can pass a high key tuple in the hopes of having
- * us set *continuescan to false, and avoiding an unnecessary visit to
- * the page to the right.
+ * Forward scan callers call with a high key tuple last in the hopes of having
+ * us set pstate.continuescan to false, and avoiding an unnecessary visit to
+ * the page to the right. Pass finaltup=true for these high key calls.
+ * Backwards scan callers shouldn't do this, but should still let us know
+ * which tuple is last by passing finaltup=true for the final non-pivot tuple
+ * (the non-pivot tuple at page offset number one).
+ *
+ * Callers with equality strategy array scan keys must set up page state that
+ * helps us know when to start or stop primitive index scans on their behalf.
+ * The finaltup tuple should be stashed in pstate.finaltup, so we don't have
+ * to wait until the finaltup call to be able to see what's up with the page.
+ *
+ * Advances the scan's array keys in passing when required. Note that we rely
+ * on _bt_readpage calling here in page offset number order (for the current
+ * scan direction). Any other order confuses array advancement.
*
* scan: index scan descriptor (containing a search-type scankey)
+ * pstate: Page level input and output parameters
* tuple: index tuple to test
+ * finaltup: Is tuple the final one we'll be called with for this page?
* tupnatts: number of attributes in tupnatts (high key may be truncated)
- * dir: direction we are scanning in
- * continuescan: output parameter (will be set correctly in all cases)
* requiredMatchedByPrecheck: indicates that scan keys required for
* direction scan are already matched
*/
bool
-_bt_checkkeys(IndexScanDesc scan, IndexTuple tuple, int tupnatts,
- ScanDirection dir, bool *continuescan,
+_bt_checkkeys(IndexScanDesc scan, BTReadPageState *pstate,
+ IndexTuple tuple, bool finaltup, int tupnatts,
bool requiredMatchedByPrecheck)
{
- TupleDesc tupdesc;
- BTScanOpaque so;
- int keysz;
- int ikey;
- ScanKey key;
+ TupleDesc tupdesc = RelationGetDescr(scan->indexRelation);
+ BTScanOpaque so = (BTScanOpaque) scan->opaque;
+ int numArrayKeys = so->numArrayKeys;
+ int ikey = 0;
+ bool res;
Assert(BTreeTupleGetNAtts(tuple, scan->indexRelation) == tupnatts);
+ Assert(pstate->continuescan);
+ Assert(!numArrayKeys || so->advanceDir == pstate->dir);
+ Assert(!so->needPrimScan);
+
+ res = _bt_check_compare(pstate->dir, so, tuple, tupnatts, tupdesc,
+ numArrayKeys, &pstate->continuescan, &ikey,
+ requiredMatchedByPrecheck);
+
+ /*
+ * Only one _bt_check_compare call is required in the common case where
+ * there are no equality-type array scan keys. Otherwise we can only
+ * accept _bt_check_compare's answer unreservedly when it didn't set
+ * continuescan=false.
+ */
+ if (!numArrayKeys || pstate->continuescan)
+ return res;
+
+ /*
+ * _bt_check_compare call set continuescan=false in the presence of
+ * equality type array keys.
+ *
+ * While we might really need to end the top-level index scan, most of the
+ * time this just means that the scan needs to reconsider its array keys.
+ */
+ if (_bt_tuple_before_array_skeys(scan, pstate, tuple, ikey, true))
+ {
+ /*
+ * Current tuple is < the current array scan keys/equality constraints
+ * (or > in the backward scan case). Don't need to advance the array
+ * keys. Must decide whether to start a new primitive scan instead.
+ *
+ * If this tuple isn't the finaltup for the page, then recheck the
+ * finaltup stashed in pstate as an optimization. That allows us to
+ * quit scanning this page early when it's clearly hopeless (we don't
+ * need to wait for the finaltup call to give up on a primitive scan).
+ */
+ if (finaltup || (!pstate->finaltupchecked && pstate->finaltup &&
+ _bt_tuple_before_array_skeys(scan, pstate,
+ pstate->finaltup,
+ 0, false)))
+ {
+ /*
+ * Give up on the ongoing primitive index scan.
+ *
+ * Even the final tuple (the high key for forward scans, or the
+ * tuple from page offset number 1 for backward scans) is before
+ * the current array keys. That strongly suggests that continuing
+ * this primitive scan would be less efficient than starting anew.
+ *
+ * See also: _bt_advance_array_keys's handling of the case where
+ * finaltup itself advances the array keys to non-matching values.
+ */
+ pstate->continuescan = false;
+
+ /*
+ * Set up a new primitive index scan that will reposition the
+ * top-level scan to the first leaf page whose key space is
+ * covered by our array keys. The top-level scan will "skip" a
+ * part of the index that can only contain non-matching tuples.
+ *
+ * Note: the next primitive index scan is guaranteed to land on
+ * some later leaf page (ideally it won't be this page's sibling).
+ * It follows that the top-level scan can never access the same
+ * leaf page more than once (unless the scan changes direction or
+ * btrestrpos is called). btcostestimate relies on this.
+ */
+ so->needPrimScan = true;
+ }
+ else
+ {
+ /*
+ * Stick with the ongoing primitive index scan, for now (override
+ * _bt_check_compare's suggestion that we end the scan).
+ *
+ * Note: we will end up here again and again given a group of
+ * tuples > the previous array keys and < the now-current keys
+ * (though only after an initial finaltup precheck determined that
+ * this page definitely covers key space from both array keysets).
+ * In effect, we perform a linear search of the page's remaining
+ * unscanned tuples every time the arrays advance past the key
+ * space of the scan's then-current tuple.
+ */
+ pstate->continuescan = true;
+
+ /*
+ * Our finaltup precheck determined that it is >= the current keys
+ * (though the _current_ tuple is still < the current array keys).
+ *
+ * Remember that fact in pstate now. This avoids wasting cycles
+ * on repeating the same precheck step (checking the same finaltup
+ * against the same array keys) during later calls here for later
+ * tuples from this same leaf page.
+ */
+ pstate->finaltupchecked = true;
+ }
+
+ /* In any case, this indextuple doesn't match the qual */
+ return false;
+ }
+
+ /*
+ * Caller's tuple is >= the current set of array keys and other equality
+ * constraint scan keys (or <= if this is a backwards scans). It's now
+ * clear that we _must_ advance any required array keys in lockstep with
+ * the scan (unless the required array keys become exhausted instead, or
+ * unless the ikey trigger corresponds to a non-required array scan key).
+ *
+ * Note: we might even advance the required arrays when all existing keys
+ * are already equal to the values from the tuple at this point. See the
+ * comments above _bt_advance_array_keys about required-inequality-driven
+ * array advancement.
+ *
+ * Note: we _won't_ advance any required arrays when the ikey/trigger scan
+ * key corresponds to a non-required array found to be unsatisfied by the
+ * current keys. (We might not even "advance" the non-required array.)
+ */
+ return _bt_advance_array_keys(scan, pstate, tuple, ikey);
+}
+
+/*
+ * Test whether an indextuple satisfies current scan condition.
+ *
+ * Return true if so, false if not. If not, also clear *continuescan if
+ * it's not possible for any future tuples in the current scan direction to
+ * pass the qual with the current set of array keys.
+ *
+ * This is a subroutine for _bt_checkkeys. It is written with the assumption
+ * that reaching the end of each distinct set of array keys terminates the
+ * ongoing primitive index scan. It is up to our caller (which has more high
+ * level context than us) to override that initial determination when it makes
+ * more sense to advance the array keys and continue with further tuples from
+ * the same leaf page.
+ */
+static bool
+_bt_check_compare(ScanDirection dir, BTScanOpaque so,
+ IndexTuple tuple, int tupnatts, TupleDesc tupdesc,
+ int numArrayKeys, bool *continuescan, int *ikey,
+ bool requiredMatchedByPrecheck)
+{
+ ScanKey key;
+ int keysz;
+
+ Assert(!numArrayKeys || !requiredMatchedByPrecheck);
*continuescan = true; /* default assumption */
-
- tupdesc = RelationGetDescr(scan->indexRelation);
- so = (BTScanOpaque) scan->opaque;
keysz = so->numberOfKeys;
- for (key = so->keyData, ikey = 0; ikey < keysz; key++, ikey++)
+ for (key = so->keyData + *ikey; *ikey < keysz; key++, (*ikey)++)
{
Datum datum;
bool isNull;
Datum test;
bool requiredSameDir = false,
- requiredOppositeDir = false;
+ requiredOppositeDirOnly = false;
/*
- * Check if the key is required for ordered scan in the same or
- * opposite direction. Save as flag variables for future usage.
+ * Check if the key is required in the current scan direction, in the
+ * opposite scan direction _only_, or in neither direction
*/
if (((key->sk_flags & SK_BT_REQFWD) && ScanDirectionIsForward(dir)) ||
((key->sk_flags & SK_BT_REQBKWD) && ScanDirectionIsBackward(dir)))
requiredSameDir = true;
else if (((key->sk_flags & SK_BT_REQFWD) && ScanDirectionIsBackward(dir)) ||
((key->sk_flags & SK_BT_REQBKWD) && ScanDirectionIsForward(dir)))
- requiredOppositeDir = true;
+ requiredOppositeDirOnly = true;
/*
* Is the key required for scanning for either forward or backward
@@ -1411,7 +2956,7 @@ _bt_checkkeys(IndexScanDesc scan, IndexTuple tuple, int tupnatts,
* known to be matched, skip the check. Except for the row keys,
* where NULLs could be found in the middle of matching values.
*/
- if ((requiredSameDir || requiredOppositeDir) &&
+ if ((requiredSameDir || requiredOppositeDirOnly) &&
!(key->sk_flags & SK_ROW_HEADER) && requiredMatchedByPrecheck)
continue;
@@ -1423,7 +2968,6 @@ _bt_checkkeys(IndexScanDesc scan, IndexTuple tuple, int tupnatts,
* right could be any possible value. Assume that truncated
* attribute passes the qual.
*/
- Assert(ScanDirectionIsForward(dir));
Assert(BTreeTupleIsPivot(tuple));
continue;
}
@@ -1514,11 +3058,28 @@ _bt_checkkeys(IndexScanDesc scan, IndexTuple tuple, int tupnatts,
/*
* Apply the key checking function. When the key is required for
- * opposite direction scan, it must be already satisfied by
- * _bt_first() except for the NULLs checking, which have already done
- * above.
+ * opposite-direction scans it must be an inequality satisfied by
+ * _bt_first(), barring NULLs, which we just checked a moment ago.
+ *
+ * (Also can't apply this optimization with scans that use arrays,
+ * since _bt_advance_array_keys() sometimes allows the scan to see a
+ * few tuples from before the would-be _bt_first() starting position
+ * for the scan's just-advanced array keys.)
+ *
+ * Even required equality quals (that can't use this optimization due
+ * to being required in both scan directions) rely on the assumption
+ * that _bt_first() will always use the quals for initial positioning
+ * purposes. We stop the scan as soon as any required equality qual
+ * fails, so it had better only happen at the end of equal tuples in
+ * the current scan direction (never at the start of equal tuples).
+ * See comments in _bt_first().
+ *
+ * (The required equality quals issue also has specific implications
+ * for scans that use arrays. They sometimes perform a linear search
+ * of remaining unscanned tuples, forcing the primitive index scan to
+ * continue until it locates tuples >= the scan's new array keys.)
*/
- if (!requiredOppositeDir)
+ if (!requiredOppositeDirOnly || numArrayKeys)
{
test = FunctionCall2Coll(&key->sk_func, key->sk_collation,
datum, key->sk_argument);
@@ -1536,15 +3097,25 @@ _bt_checkkeys(IndexScanDesc scan, IndexTuple tuple, int tupnatts,
* Tuple fails this qual. If it's a required qual for the current
* scan direction, then we can conclude no further tuples will
* pass, either.
- *
- * Note: because we stop the scan as soon as any required equality
- * qual fails, it is critical that equality quals be used for the
- * initial positioning in _bt_first() when they are available. See
- * comments in _bt_first().
*/
if (requiredSameDir)
*continuescan = false;
+ /*
+ * Always set continuescan=false for equality-type array keys that
+ * don't pass -- even for an array scan key not marked required.
+ *
+ * A non-required scan key (array or otherwise) can never actually
+ * terminate the scan. It's just convenient for callers to treat
+ * continuescan=false as a signal that it might be time to advance
+ * the array keys, independent of whether they're required or not.
+ * (Even setting continuescan=false with a required scan key won't
+ * usually end a scan that uses arrays.)
+ */
+ if (numArrayKeys && (key->sk_flags & SK_SEARCHARRAY) &&
+ key->sk_strategy == BTEqualStrategyNumber)
+ *continuescan = false;
+
/*
* In any case, this indextuple doesn't match the qual.
*/
@@ -1563,7 +3134,7 @@ _bt_checkkeys(IndexScanDesc scan, IndexTuple tuple, int tupnatts,
* it's not possible for any future tuples in the current scan direction
* to pass the qual.
*
- * This is a subroutine for _bt_checkkeys, which see for more info.
+ * This is a subroutine for _bt_checkkeys/_bt_check_compare.
*/
static bool
_bt_check_rowcompare(ScanKey skey, IndexTuple tuple, int tupnatts,
@@ -1592,7 +3163,6 @@ _bt_check_rowcompare(ScanKey skey, IndexTuple tuple, int tupnatts,
* right could be any possible value. Assume that truncated
* attribute passes the qual.
*/
- Assert(ScanDirectionIsForward(dir));
Assert(BTreeTupleIsPivot(tuple));
cmpresult = 0;
if (subkey->sk_flags & SK_ROW_END)
diff --git a/src/backend/optimizer/path/indxpath.c b/src/backend/optimizer/path/indxpath.c
index 03a5fbdc6..e37597c26 100644
--- a/src/backend/optimizer/path/indxpath.c
+++ b/src/backend/optimizer/path/indxpath.c
@@ -106,8 +106,7 @@ static List *build_index_paths(PlannerInfo *root, RelOptInfo *rel,
IndexOptInfo *index, IndexClauseSet *clauses,
bool useful_predicate,
ScanTypeControl scantype,
- bool *skip_nonnative_saop,
- bool *skip_lower_saop);
+ bool *skip_nonnative_saop);
static List *build_paths_for_OR(PlannerInfo *root, RelOptInfo *rel,
List *clauses, List *other_clauses);
static List *generate_bitmap_or_paths(PlannerInfo *root, RelOptInfo *rel,
@@ -706,8 +705,6 @@ eclass_already_used(EquivalenceClass *parent_ec, Relids oldrelids,
* index AM supports them natively, we should just include them in simple
* index paths. If not, we should exclude them while building simple index
* paths, and then make a separate attempt to include them in bitmap paths.
- * Furthermore, we should consider excluding lower-order ScalarArrayOpExpr
- * quals so as to create ordered paths.
*/
static void
get_index_paths(PlannerInfo *root, RelOptInfo *rel,
@@ -716,37 +713,17 @@ get_index_paths(PlannerInfo *root, RelOptInfo *rel,
{
List *indexpaths;
bool skip_nonnative_saop = false;
- bool skip_lower_saop = false;
ListCell *lc;
/*
* Build simple index paths using the clauses. Allow ScalarArrayOpExpr
- * clauses only if the index AM supports them natively, and skip any such
- * clauses for index columns after the first (so that we produce ordered
- * paths if possible).
+ * clauses only if the index AM supports them natively.
*/
indexpaths = build_index_paths(root, rel,
index, clauses,
index->predOK,
ST_ANYSCAN,
- &skip_nonnative_saop,
- &skip_lower_saop);
-
- /*
- * If we skipped any lower-order ScalarArrayOpExprs on an index with an AM
- * that supports them, then try again including those clauses. This will
- * produce paths with more selectivity but no ordering.
- */
- if (skip_lower_saop)
- {
- indexpaths = list_concat(indexpaths,
- build_index_paths(root, rel,
- index, clauses,
- index->predOK,
- ST_ANYSCAN,
- &skip_nonnative_saop,
- NULL));
- }
+ &skip_nonnative_saop);
/*
* Submit all the ones that can form plain IndexScan plans to add_path. (A
@@ -784,7 +761,6 @@ get_index_paths(PlannerInfo *root, RelOptInfo *rel,
index, clauses,
false,
ST_BITMAPSCAN,
- NULL,
NULL);
*bitindexpaths = list_concat(*bitindexpaths, indexpaths);
}
@@ -817,27 +793,19 @@ get_index_paths(PlannerInfo *root, RelOptInfo *rel,
* to true if we found any such clauses (caller must initialize the variable
* to false). If it's NULL, we do not ignore ScalarArrayOpExpr clauses.
*
- * If skip_lower_saop is non-NULL, we ignore ScalarArrayOpExpr clauses for
- * non-first index columns, and we set *skip_lower_saop to true if we found
- * any such clauses (caller must initialize the variable to false). If it's
- * NULL, we do not ignore non-first ScalarArrayOpExpr clauses, but they will
- * result in considering the scan's output to be unordered.
- *
* 'rel' is the index's heap relation
* 'index' is the index for which we want to generate paths
* 'clauses' is the collection of indexable clauses (IndexClause nodes)
* 'useful_predicate' indicates whether the index has a useful predicate
* 'scantype' indicates whether we need plain or bitmap scan support
* 'skip_nonnative_saop' indicates whether to accept SAOP if index AM doesn't
- * 'skip_lower_saop' indicates whether to accept non-first-column SAOP
*/
static List *
build_index_paths(PlannerInfo *root, RelOptInfo *rel,
IndexOptInfo *index, IndexClauseSet *clauses,
bool useful_predicate,
ScanTypeControl scantype,
- bool *skip_nonnative_saop,
- bool *skip_lower_saop)
+ bool *skip_nonnative_saop)
{
List *result = NIL;
IndexPath *ipath;
@@ -848,7 +816,6 @@ build_index_paths(PlannerInfo *root, RelOptInfo *rel,
List *orderbyclausecols;
List *index_pathkeys;
List *useful_pathkeys;
- bool found_lower_saop_clause;
bool pathkeys_possibly_useful;
bool index_is_ordered;
bool index_only_scan;
@@ -880,19 +847,11 @@ build_index_paths(PlannerInfo *root, RelOptInfo *rel,
* on by btree and possibly other places.) The list can be empty, if the
* index AM allows that.
*
- * found_lower_saop_clause is set true if we accept a ScalarArrayOpExpr
- * index clause for a non-first index column. This prevents us from
- * assuming that the scan result is ordered. (Actually, the result is
- * still ordered if there are equality constraints for all earlier
- * columns, but it seems too expensive and non-modular for this code to be
- * aware of that refinement.)
- *
* We also build a Relids set showing which outer rels are required by the
* selected clauses. Any lateral_relids are included in that, but not
* otherwise accounted for.
*/
index_clauses = NIL;
- found_lower_saop_clause = false;
outer_relids = bms_copy(rel->lateral_relids);
for (indexcol = 0; indexcol < index->nkeycolumns; indexcol++)
{
@@ -903,30 +862,20 @@ build_index_paths(PlannerInfo *root, RelOptInfo *rel,
IndexClause *iclause = (IndexClause *) lfirst(lc);
RestrictInfo *rinfo = iclause->rinfo;
- /* We might need to omit ScalarArrayOpExpr clauses */
- if (IsA(rinfo->clause, ScalarArrayOpExpr))
+ /*
+ * We might need to omit ScalarArrayOpExpr clauses when index AM
+ * lacks native support
+ */
+ if (!index->amsearcharray && IsA(rinfo->clause, ScalarArrayOpExpr))
{
- if (!index->amsearcharray)
+ if (skip_nonnative_saop)
{
- if (skip_nonnative_saop)
- {
- /* Ignore because not supported by index */
- *skip_nonnative_saop = true;
- continue;
- }
- /* Caller had better intend this only for bitmap scan */
- Assert(scantype == ST_BITMAPSCAN);
- }
- if (indexcol > 0)
- {
- if (skip_lower_saop)
- {
- /* Caller doesn't want to lose index ordering */
- *skip_lower_saop = true;
- continue;
- }
- found_lower_saop_clause = true;
+ /* Ignore because not supported by index */
+ *skip_nonnative_saop = true;
+ continue;
}
+ /* Caller had better intend this only for bitmap scan */
+ Assert(scantype == ST_BITMAPSCAN);
}
/* OK to include this clause */
@@ -956,11 +905,9 @@ build_index_paths(PlannerInfo *root, RelOptInfo *rel,
/*
* 2. Compute pathkeys describing index's ordering, if any, then see how
* many of them are actually useful for this query. This is not relevant
- * if we are only trying to build bitmap indexscans, nor if we have to
- * assume the scan is unordered.
+ * if we are only trying to build bitmap indexscans.
*/
pathkeys_possibly_useful = (scantype != ST_BITMAPSCAN &&
- !found_lower_saop_clause &&
has_useful_pathkeys(root, rel));
index_is_ordered = (index->sortopfamily != NULL);
if (index_is_ordered && pathkeys_possibly_useful)
@@ -1212,7 +1159,6 @@ build_paths_for_OR(PlannerInfo *root, RelOptInfo *rel,
index, &clauseset,
useful_predicate,
ST_BITMAPSCAN,
- NULL,
NULL);
result = list_concat(result, indexpaths);
}
diff --git a/src/backend/utils/adt/selfuncs.c b/src/backend/utils/adt/selfuncs.c
index e11d02282..f96c7b5dc 100644
--- a/src/backend/utils/adt/selfuncs.c
+++ b/src/backend/utils/adt/selfuncs.c
@@ -6514,8 +6514,6 @@ genericcostestimate(PlannerInfo *root,
double numIndexTuples;
double spc_random_page_cost;
double num_sa_scans;
- double num_outer_scans;
- double num_scans;
double qual_op_cost;
double qual_arg_cost;
List *selectivityQuals;
@@ -6530,7 +6528,7 @@ genericcostestimate(PlannerInfo *root,
/*
* Check for ScalarArrayOpExpr index quals, and estimate the number of
- * index scans that will be performed.
+ * primitive index scans that will be performed for caller
*/
num_sa_scans = 1;
foreach(l, indexQuals)
@@ -6560,19 +6558,8 @@ genericcostestimate(PlannerInfo *root,
*/
numIndexTuples = costs->numIndexTuples;
if (numIndexTuples <= 0.0)
- {
numIndexTuples = indexSelectivity * index->rel->tuples;
- /*
- * The above calculation counts all the tuples visited across all
- * scans induced by ScalarArrayOpExpr nodes. We want to consider the
- * average per-indexscan number, so adjust. This is a handy place to
- * round to integer, too. (If caller supplied tuple estimate, it's
- * responsible for handling these considerations.)
- */
- numIndexTuples = rint(numIndexTuples / num_sa_scans);
- }
-
/*
* We can bound the number of tuples by the index size in any case. Also,
* always estimate at least one tuple is touched, even when
@@ -6610,27 +6597,31 @@ genericcostestimate(PlannerInfo *root,
*
* The above calculations are all per-index-scan. However, if we are in a
* nestloop inner scan, we can expect the scan to be repeated (with
- * different search keys) for each row of the outer relation. Likewise,
- * ScalarArrayOpExpr quals result in multiple index scans. This creates
- * the potential for cache effects to reduce the number of disk page
- * fetches needed. We want to estimate the average per-scan I/O cost in
- * the presence of caching.
+ * different search keys) for each row of the outer relation. This
+ * creates the potential for cache effects to reduce the number of disk
+ * page fetches needed. We want to estimate the average per-scan I/O cost
+ * in the presence of caching.
*
* We use the Mackert-Lohman formula (see costsize.c for details) to
* estimate the total number of page fetches that occur. While this
* wasn't what it was designed for, it seems a reasonable model anyway.
* Note that we are counting pages not tuples anymore, so we take N = T =
* index size, as if there were one "tuple" per page.
+ *
+ * Note: we assume that there will be no repeat index page fetches across
+ * ScalarArrayOpExpr primitive scans from the same logical index scan.
+ * This is guaranteed to be true for btree indexes, but is very optimistic
+ * with index AMs that cannot natively execute ScalarArrayOpExpr quals.
+ * However, these same index AMs also accept our default pessimistic
+ * approach to counting num_sa_scans (btree caller caps this), so we don't
+ * expect the final indexTotalCost to be wildly over-optimistic.
*/
- num_outer_scans = loop_count;
- num_scans = num_sa_scans * num_outer_scans;
-
- if (num_scans > 1)
+ if (loop_count > 1)
{
double pages_fetched;
/* total page fetches ignoring cache effects */
- pages_fetched = numIndexPages * num_scans;
+ pages_fetched = numIndexPages * loop_count;
/* use Mackert and Lohman formula to adjust for cache effects */
pages_fetched = index_pages_fetched(pages_fetched,
@@ -6640,11 +6631,9 @@ genericcostestimate(PlannerInfo *root,
/*
* Now compute the total disk access cost, and then report a pro-rated
- * share for each outer scan. (Don't pro-rate for ScalarArrayOpExpr,
- * since that's internal to the indexscan.)
+ * share for each outer scan
*/
- indexTotalCost = (pages_fetched * spc_random_page_cost)
- / num_outer_scans;
+ indexTotalCost = (pages_fetched * spc_random_page_cost) / loop_count;
}
else
{
@@ -6660,10 +6649,8 @@ genericcostestimate(PlannerInfo *root,
* evaluated once at the start of the scan to reduce them to runtime keys
* to pass to the index AM (see nodeIndexscan.c). We model the per-tuple
* CPU costs as cpu_index_tuple_cost plus one cpu_operator_cost per
- * indexqual operator. Because we have numIndexTuples as a per-scan
- * number, we have to multiply by num_sa_scans to get the correct result
- * for ScalarArrayOpExpr cases. Similarly add in costs for any index
- * ORDER BY expressions.
+ * indexqual operator. Similarly add in costs for any index ORDER BY
+ * expressions.
*
* Note: this neglects the possible costs of rechecking lossy operators.
* Detecting that that might be needed seems more expensive than it's
@@ -6676,7 +6663,7 @@ genericcostestimate(PlannerInfo *root,
indexStartupCost = qual_arg_cost;
indexTotalCost += qual_arg_cost;
- indexTotalCost += numIndexTuples * num_sa_scans * (cpu_index_tuple_cost + qual_op_cost);
+ indexTotalCost += numIndexTuples * (cpu_index_tuple_cost + qual_op_cost);
/*
* Generic assumption about index correlation: there isn't any.
@@ -6754,7 +6741,6 @@ btcostestimate(PlannerInfo *root, IndexPath *path, double loop_count,
bool eqQualHere;
bool found_saop;
bool found_is_null_op;
- double num_sa_scans;
ListCell *lc;
/*
@@ -6769,17 +6755,12 @@ btcostestimate(PlannerInfo *root, IndexPath *path, double loop_count,
*
* For a RowCompareExpr, we consider only the first column, just as
* rowcomparesel() does.
- *
- * If there's a ScalarArrayOpExpr in the quals, we'll actually perform N
- * index scans not one, but the ScalarArrayOpExpr's operator can be
- * considered to act the same as it normally does.
*/
indexBoundQuals = NIL;
indexcol = 0;
eqQualHere = false;
found_saop = false;
found_is_null_op = false;
- num_sa_scans = 1;
foreach(lc, path->indexclauses)
{
IndexClause *iclause = lfirst_node(IndexClause, lc);
@@ -6819,14 +6800,9 @@ btcostestimate(PlannerInfo *root, IndexPath *path, double loop_count,
else if (IsA(clause, ScalarArrayOpExpr))
{
ScalarArrayOpExpr *saop = (ScalarArrayOpExpr *) clause;
- Node *other_operand = (Node *) lsecond(saop->args);
- int alength = estimate_array_length(other_operand);
clause_op = saop->opno;
found_saop = true;
- /* count number of SA scans induced by indexBoundQuals only */
- if (alength > 1)
- num_sa_scans *= alength;
}
else if (IsA(clause, NullTest))
{
@@ -6886,13 +6862,6 @@ btcostestimate(PlannerInfo *root, IndexPath *path, double loop_count,
JOIN_INNER,
NULL);
numIndexTuples = btreeSelectivity * index->rel->tuples;
-
- /*
- * As in genericcostestimate(), we have to adjust for any
- * ScalarArrayOpExpr quals included in indexBoundQuals, and then round
- * to integer.
- */
- numIndexTuples = rint(numIndexTuples / num_sa_scans);
}
/*
@@ -6902,6 +6871,48 @@ btcostestimate(PlannerInfo *root, IndexPath *path, double loop_count,
genericcostestimate(root, path, loop_count, &costs);
+ /*
+ * Now compensate for btree's ability to efficiently execute scans with
+ * SAOP clauses.
+ *
+ * btree automatically combines individual ScalarArrayOpExpr primitive
+ * index scans whenever the tuples covered by the next set of array keys
+ * are close to tuples covered by the current set. This makes the final
+ * number of descents particularly difficult to estimate. However, btree
+ * scans never visit any single leaf page more than once. That puts a
+ * natural floor under the worst case number of descents.
+ *
+ * It's particularly important that we not wildly overestimate the number
+ * of descents needed for a clause list with several SAOPs -- the costs
+ * really aren't multiplicative in the way genericcostestimate expects. In
+ * general, most distinct combinations of SAOP keys will tend to not find
+ * any matching tuples. Furthermore, btree scans search for the next set
+ * of array keys using the next tuple in line, and so won't even need a
+ * direct comparison to eliminate most non-matching sets of array keys.
+ *
+ * Clamp the number of descents to the estimated number of leaf page
+ * visits. This is still fairly pessimistic, but tends to result in more
+ * accurate costing of scans with several SAOP clauses -- especially when
+ * each array has more than a few elements. The cost of adding additional
+ * array constants to a low-order SAOP column should saturate past a
+ * certain point (except where selectivity estimates continue to shift).
+ *
+ * Also clamp the number of descents to 1/3 the number of index pages.
+ * This avoids implausibly high estimates with low selectivity paths,
+ * where scans frequently require no more than one or two descents.
+ *
+ * XXX Ideally, we'd also account for the fact that non-boundary SAOP
+ * clause quals (which the B-Tree code uses "non-required" scan keys for)
+ * won't actually contribute to the total number of descents of the index.
+ * This would require pushing down more context into genericcostestimate.
+ */
+ if (costs.num_sa_scans > 1)
+ {
+ costs.num_sa_scans = Min(costs.num_sa_scans, costs.numIndexPages);
+ costs.num_sa_scans = Min(costs.num_sa_scans, index->pages / 3);
+ costs.num_sa_scans = Max(costs.num_sa_scans, 1);
+ }
+
/*
* Add a CPU-cost component to represent the costs of initial btree
* descent. We don't charge any I/O cost for touching upper btree levels,
@@ -6909,9 +6920,9 @@ btcostestimate(PlannerInfo *root, IndexPath *path, double loop_count,
* comparisons to descend a btree of N leaf tuples. We charge one
* cpu_operator_cost per comparison.
*
- * If there are ScalarArrayOpExprs, charge this once per SA scan. The
- * ones after the first one are not startup cost so far as the overall
- * plan is concerned, so add them only to "total" cost.
+ * If there are ScalarArrayOpExprs, charge this once per estimated
+ * primitive SA scan. The ones after the first one are not startup cost
+ * so far as the overall plan goes, so just add them to "total" cost.
*/
if (index->tuples > 1) /* avoid computing log(0) */
{
@@ -6928,7 +6939,8 @@ btcostestimate(PlannerInfo *root, IndexPath *path, double loop_count,
* in cases where only a single leaf page is expected to be visited. This
* cost is somewhat arbitrarily set at 50x cpu_operator_cost per page
* touched. The number of such pages is btree tree height plus one (ie,
- * we charge for the leaf page too). As above, charge once per SA scan.
+ * we charge for the leaf page too). As above, charge once per estimated
+ * primitive SA scan.
*/
descentCost = (index->tree_height + 1) * DEFAULT_PAGE_CPU_MULTIPLIER * cpu_operator_cost;
costs.indexStartupCost += descentCost;
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 42509042a..38523b832 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -4035,6 +4035,21 @@ description | Waiting for a newly initialized WAL file to reach durable storage
</para>
</note>
+ <note>
+ <para>
+ Every time an index is searched, the index's
+ <structname>pg_stat_all_indexes</structname>.<structfield>idx_scan</structfield>
+ field is incremented. This usually happens once per index scan node
+ execution, but might take place several times during execution of a scan
+ that searches for multiple values together. Queries that use certain
+ <acronym>SQL</acronym> constructs to search for rows matching any value
+ out of a list (or an array) of multiple scalar values might perform
+ multiple <quote>primitive</quote> index scans (up to one primitive scan
+ per scalar value) at runtime. See <xref linkend="functions-comparisons"/>
+ for details.
+ </para>
+ </note>
+
</sect2>
<sect2 id="monitoring-pg-statio-all-tables-view">
diff --git a/src/test/regress/expected/btree_index.out b/src/test/regress/expected/btree_index.out
index 8311a03c3..d159091ab 100644
--- a/src/test/regress/expected/btree_index.out
+++ b/src/test/regress/expected/btree_index.out
@@ -434,3 +434,482 @@ ALTER INDEX btree_part_idx ALTER COLUMN id SET (n_distinct=100);
ERROR: ALTER action ALTER COLUMN ... SET cannot be performed on relation "btree_part_idx"
DETAIL: This operation is not supported for partitioned indexes.
DROP TABLE btree_part;
+-- Add tests to give coverage of various subtle issues.
+--
+-- XXX This may not be suitable for commit, due to taking up too many cycles.
+--
+-- Here we don't remember the scan's array keys before processing a page, only
+-- after processing a page (which is implicit, it's just the scan's current
+-- keys). So when we move the scan backwards we think that the top-level scan
+-- should terminate, when in reality it should jump backwards to the leaf page
+-- that we last visited.
+create temp table backup_wrong_tbl (district int4, warehouse int4, orderid int4, orderline int4);
+create index backup_wrong_idx on backup_wrong_tbl (district, warehouse, orderid, orderline);
+insert into backup_wrong_tbl
+select district, warehouse, orderid, orderline
+from
+ generate_series(1, 3) district,
+ generate_series(1, 2) warehouse,
+ generate_series(1, 51) orderid,
+ generate_series(1, 10) orderline;
+begin;
+declare back_up_terminate_toplevel_wrong cursor for
+select * from backup_wrong_tbl
+where district in (1, 3) and warehouse in (1,2)
+and orderid in (48, 50)
+order by district, warehouse, orderid, orderline;
+fetch forward 60 from back_up_terminate_toplevel_wrong;
+ district | warehouse | orderid | orderline
+----------+-----------+---------+-----------
+ 1 | 1 | 48 | 1
+ 1 | 1 | 48 | 2
+ 1 | 1 | 48 | 3
+ 1 | 1 | 48 | 4
+ 1 | 1 | 48 | 5
+ 1 | 1 | 48 | 6
+ 1 | 1 | 48 | 7
+ 1 | 1 | 48 | 8
+ 1 | 1 | 48 | 9
+ 1 | 1 | 48 | 10
+ 1 | 1 | 50 | 1
+ 1 | 1 | 50 | 2
+ 1 | 1 | 50 | 3
+ 1 | 1 | 50 | 4
+ 1 | 1 | 50 | 5
+ 1 | 1 | 50 | 6
+ 1 | 1 | 50 | 7
+ 1 | 1 | 50 | 8
+ 1 | 1 | 50 | 9
+ 1 | 1 | 50 | 10
+ 1 | 2 | 48 | 1
+ 1 | 2 | 48 | 2
+ 1 | 2 | 48 | 3
+ 1 | 2 | 48 | 4
+ 1 | 2 | 48 | 5
+ 1 | 2 | 48 | 6
+ 1 | 2 | 48 | 7
+ 1 | 2 | 48 | 8
+ 1 | 2 | 48 | 9
+ 1 | 2 | 48 | 10
+ 1 | 2 | 50 | 1
+ 1 | 2 | 50 | 2
+ 1 | 2 | 50 | 3
+ 1 | 2 | 50 | 4
+ 1 | 2 | 50 | 5
+ 1 | 2 | 50 | 6
+ 1 | 2 | 50 | 7
+ 1 | 2 | 50 | 8
+ 1 | 2 | 50 | 9
+ 1 | 2 | 50 | 10
+ 3 | 1 | 48 | 1
+ 3 | 1 | 48 | 2
+ 3 | 1 | 48 | 3
+ 3 | 1 | 48 | 4
+ 3 | 1 | 48 | 5
+ 3 | 1 | 48 | 6
+ 3 | 1 | 48 | 7
+ 3 | 1 | 48 | 8
+ 3 | 1 | 48 | 9
+ 3 | 1 | 48 | 10
+ 3 | 1 | 50 | 1
+ 3 | 1 | 50 | 2
+ 3 | 1 | 50 | 3
+ 3 | 1 | 50 | 4
+ 3 | 1 | 50 | 5
+ 3 | 1 | 50 | 6
+ 3 | 1 | 50 | 7
+ 3 | 1 | 50 | 8
+ 3 | 1 | 50 | 9
+ 3 | 1 | 50 | 10
+(60 rows)
+
+fetch backward 29 from back_up_terminate_toplevel_wrong;
+ district | warehouse | orderid | orderline
+----------+-----------+---------+-----------
+ 3 | 1 | 50 | 9
+ 3 | 1 | 50 | 8
+ 3 | 1 | 50 | 7
+ 3 | 1 | 50 | 6
+ 3 | 1 | 50 | 5
+ 3 | 1 | 50 | 4
+ 3 | 1 | 50 | 3
+ 3 | 1 | 50 | 2
+ 3 | 1 | 50 | 1
+ 3 | 1 | 48 | 10
+ 3 | 1 | 48 | 9
+ 3 | 1 | 48 | 8
+ 3 | 1 | 48 | 7
+ 3 | 1 | 48 | 6
+ 3 | 1 | 48 | 5
+ 3 | 1 | 48 | 4
+ 3 | 1 | 48 | 3
+ 3 | 1 | 48 | 2
+ 3 | 1 | 48 | 1
+ 1 | 2 | 50 | 10
+ 1 | 2 | 50 | 9
+ 1 | 2 | 50 | 8
+ 1 | 2 | 50 | 7
+ 1 | 2 | 50 | 6
+ 1 | 2 | 50 | 5
+ 1 | 2 | 50 | 4
+ 1 | 2 | 50 | 3
+ 1 | 2 | 50 | 2
+ 1 | 2 | 50 | 1
+(29 rows)
+
+fetch forward 12 from back_up_terminate_toplevel_wrong;
+ district | warehouse | orderid | orderline
+----------+-----------+---------+-----------
+ 1 | 2 | 50 | 2
+ 1 | 2 | 50 | 3
+ 1 | 2 | 50 | 4
+ 1 | 2 | 50 | 5
+ 1 | 2 | 50 | 6
+ 1 | 2 | 50 | 7
+ 1 | 2 | 50 | 8
+ 1 | 2 | 50 | 9
+ 1 | 2 | 50 | 10
+ 3 | 1 | 48 | 1
+ 3 | 1 | 48 | 2
+ 3 | 1 | 48 | 3
+(12 rows)
+
+fetch backward 30 from back_up_terminate_toplevel_wrong;
+ district | warehouse | orderid | orderline
+----------+-----------+---------+-----------
+ 3 | 1 | 48 | 2
+ 3 | 1 | 48 | 1
+ 1 | 2 | 50 | 10
+ 1 | 2 | 50 | 9
+ 1 | 2 | 50 | 8
+ 1 | 2 | 50 | 7
+ 1 | 2 | 50 | 6
+ 1 | 2 | 50 | 5
+ 1 | 2 | 50 | 4
+ 1 | 2 | 50 | 3
+ 1 | 2 | 50 | 2
+ 1 | 2 | 50 | 1
+ 1 | 2 | 48 | 10
+ 1 | 2 | 48 | 9
+ 1 | 2 | 48 | 8
+ 1 | 2 | 48 | 7
+ 1 | 2 | 48 | 6
+ 1 | 2 | 48 | 5
+ 1 | 2 | 48 | 4
+ 1 | 2 | 48 | 3
+ 1 | 2 | 48 | 2
+ 1 | 2 | 48 | 1
+ 1 | 1 | 50 | 10
+ 1 | 1 | 50 | 9
+ 1 | 1 | 50 | 8
+ 1 | 1 | 50 | 7
+ 1 | 1 | 50 | 6
+ 1 | 1 | 50 | 5
+ 1 | 1 | 50 | 4
+ 1 | 1 | 50 | 3
+(30 rows)
+
+fetch forward 31 from back_up_terminate_toplevel_wrong;
+ district | warehouse | orderid | orderline
+----------+-----------+---------+-----------
+ 1 | 1 | 50 | 4
+ 1 | 1 | 50 | 5
+ 1 | 1 | 50 | 6
+ 1 | 1 | 50 | 7
+ 1 | 1 | 50 | 8
+ 1 | 1 | 50 | 9
+ 1 | 1 | 50 | 10
+ 1 | 2 | 48 | 1
+ 1 | 2 | 48 | 2
+ 1 | 2 | 48 | 3
+ 1 | 2 | 48 | 4
+ 1 | 2 | 48 | 5
+ 1 | 2 | 48 | 6
+ 1 | 2 | 48 | 7
+ 1 | 2 | 48 | 8
+ 1 | 2 | 48 | 9
+ 1 | 2 | 48 | 10
+ 1 | 2 | 50 | 1
+ 1 | 2 | 50 | 2
+ 1 | 2 | 50 | 3
+ 1 | 2 | 50 | 4
+ 1 | 2 | 50 | 5
+ 1 | 2 | 50 | 6
+ 1 | 2 | 50 | 7
+ 1 | 2 | 50 | 8
+ 1 | 2 | 50 | 9
+ 1 | 2 | 50 | 10
+ 3 | 1 | 48 | 1
+ 3 | 1 | 48 | 2
+ 3 | 1 | 48 | 3
+ 3 | 1 | 48 | 4
+(31 rows)
+
+fetch backward 32 from back_up_terminate_toplevel_wrong;
+ district | warehouse | orderid | orderline
+----------+-----------+---------+-----------
+ 3 | 1 | 48 | 3
+ 3 | 1 | 48 | 2
+ 3 | 1 | 48 | 1
+ 1 | 2 | 50 | 10
+ 1 | 2 | 50 | 9
+ 1 | 2 | 50 | 8
+ 1 | 2 | 50 | 7
+ 1 | 2 | 50 | 6
+ 1 | 2 | 50 | 5
+ 1 | 2 | 50 | 4
+ 1 | 2 | 50 | 3
+ 1 | 2 | 50 | 2
+ 1 | 2 | 50 | 1
+ 1 | 2 | 48 | 10
+ 1 | 2 | 48 | 9
+ 1 | 2 | 48 | 8
+ 1 | 2 | 48 | 7
+ 1 | 2 | 48 | 6
+ 1 | 2 | 48 | 5
+ 1 | 2 | 48 | 4
+ 1 | 2 | 48 | 3
+ 1 | 2 | 48 | 2
+ 1 | 2 | 48 | 1
+ 1 | 1 | 50 | 10
+ 1 | 1 | 50 | 9
+ 1 | 1 | 50 | 8
+ 1 | 1 | 50 | 7
+ 1 | 1 | 50 | 6
+ 1 | 1 | 50 | 5
+ 1 | 1 | 50 | 4
+ 1 | 1 | 50 | 3
+ 1 | 1 | 50 | 2
+(32 rows)
+
+fetch forward 33 from back_up_terminate_toplevel_wrong;
+ district | warehouse | orderid | orderline
+----------+-----------+---------+-----------
+ 1 | 1 | 50 | 3
+ 1 | 1 | 50 | 4
+ 1 | 1 | 50 | 5
+ 1 | 1 | 50 | 6
+ 1 | 1 | 50 | 7
+ 1 | 1 | 50 | 8
+ 1 | 1 | 50 | 9
+ 1 | 1 | 50 | 10
+ 1 | 2 | 48 | 1
+ 1 | 2 | 48 | 2
+ 1 | 2 | 48 | 3
+ 1 | 2 | 48 | 4
+ 1 | 2 | 48 | 5
+ 1 | 2 | 48 | 6
+ 1 | 2 | 48 | 7
+ 1 | 2 | 48 | 8
+ 1 | 2 | 48 | 9
+ 1 | 2 | 48 | 10
+ 1 | 2 | 50 | 1
+ 1 | 2 | 50 | 2
+ 1 | 2 | 50 | 3
+ 1 | 2 | 50 | 4
+ 1 | 2 | 50 | 5
+ 1 | 2 | 50 | 6
+ 1 | 2 | 50 | 7
+ 1 | 2 | 50 | 8
+ 1 | 2 | 50 | 9
+ 1 | 2 | 50 | 10
+ 3 | 1 | 48 | 1
+ 3 | 1 | 48 | 2
+ 3 | 1 | 48 | 3
+ 3 | 1 | 48 | 4
+ 3 | 1 | 48 | 5
+(33 rows)
+
+fetch backward 34 from back_up_terminate_toplevel_wrong;
+ district | warehouse | orderid | orderline
+----------+-----------+---------+-----------
+ 3 | 1 | 48 | 4
+ 3 | 1 | 48 | 3
+ 3 | 1 | 48 | 2
+ 3 | 1 | 48 | 1
+ 1 | 2 | 50 | 10
+ 1 | 2 | 50 | 9
+ 1 | 2 | 50 | 8
+ 1 | 2 | 50 | 7
+ 1 | 2 | 50 | 6
+ 1 | 2 | 50 | 5
+ 1 | 2 | 50 | 4
+ 1 | 2 | 50 | 3
+ 1 | 2 | 50 | 2
+ 1 | 2 | 50 | 1
+ 1 | 2 | 48 | 10
+ 1 | 2 | 48 | 9
+ 1 | 2 | 48 | 8
+ 1 | 2 | 48 | 7
+ 1 | 2 | 48 | 6
+ 1 | 2 | 48 | 5
+ 1 | 2 | 48 | 4
+ 1 | 2 | 48 | 3
+ 1 | 2 | 48 | 2
+ 1 | 2 | 48 | 1
+ 1 | 1 | 50 | 10
+ 1 | 1 | 50 | 9
+ 1 | 1 | 50 | 8
+ 1 | 1 | 50 | 7
+ 1 | 1 | 50 | 6
+ 1 | 1 | 50 | 5
+ 1 | 1 | 50 | 4
+ 1 | 1 | 50 | 3
+ 1 | 1 | 50 | 2
+ 1 | 1 | 50 | 1
+(34 rows)
+
+fetch forward 35 from back_up_terminate_toplevel_wrong;
+ district | warehouse | orderid | orderline
+----------+-----------+---------+-----------
+ 1 | 1 | 50 | 2
+ 1 | 1 | 50 | 3
+ 1 | 1 | 50 | 4
+ 1 | 1 | 50 | 5
+ 1 | 1 | 50 | 6
+ 1 | 1 | 50 | 7
+ 1 | 1 | 50 | 8
+ 1 | 1 | 50 | 9
+ 1 | 1 | 50 | 10
+ 1 | 2 | 48 | 1
+ 1 | 2 | 48 | 2
+ 1 | 2 | 48 | 3
+ 1 | 2 | 48 | 4
+ 1 | 2 | 48 | 5
+ 1 | 2 | 48 | 6
+ 1 | 2 | 48 | 7
+ 1 | 2 | 48 | 8
+ 1 | 2 | 48 | 9
+ 1 | 2 | 48 | 10
+ 1 | 2 | 50 | 1
+ 1 | 2 | 50 | 2
+ 1 | 2 | 50 | 3
+ 1 | 2 | 50 | 4
+ 1 | 2 | 50 | 5
+ 1 | 2 | 50 | 6
+ 1 | 2 | 50 | 7
+ 1 | 2 | 50 | 8
+ 1 | 2 | 50 | 9
+ 1 | 2 | 50 | 10
+ 3 | 1 | 48 | 1
+ 3 | 1 | 48 | 2
+ 3 | 1 | 48 | 3
+ 3 | 1 | 48 | 4
+ 3 | 1 | 48 | 5
+ 3 | 1 | 48 | 6
+(35 rows)
+
+commit;
+create temp table outer_table (a int, b int);
+create temp table restore_buggy_primscan_table (x int, y int);
+create index buggy_idx on restore_buggy_primscan_table (x, y) with (deduplicate_items=off);
+insert into outer_table select 1, b_vals from generate_series(1006, 1580) b_vals;
+insert into restore_buggy_primscan_table select 1, x_vals from generate_series(1006, 1580) x_vals;
+insert into outer_table select 1, 1370 from generate_series(1, 9) j;
+insert into restore_buggy_primscan_table select 1, 1371 from generate_series(1, 9) j;
+insert into restore_buggy_primscan_table select 1, 1380 from generate_series(1, 9) j;
+vacuum analyze outer_table;
+vacuum analyze restore_buggy_primscan_table;
+select count(*), o.a, o.b
+ from
+ outer_table o
+ inner join
+ restore_buggy_primscan_table bug
+ on o.a = bug.x and o.b = bug.y
+where
+ bug.x = 1 and
+ bug.y = any(array[(select array_agg(i) from generate_series(1370, 1390) i where i % 10 = 0)])
+group by o.a, o.b;
+ count | a | b
+-------+---+------
+ 10 | 1 | 1370
+ 10 | 1 | 1380
+ 1 | 1 | 1390
+(3 rows)
+
+-- Get test coverage for when so->needPrimScan is set at the point of calling
+-- _bt_restore_array_keys(). This is handled like the case where the scan
+-- direction changes "within" a page, relying on code from _bt_readnextpage().
+create temp table outer_tab(
+ a int,
+ b int
+);
+create index outer_tab_idx on outer_tab(a, b) with (deduplicate_items = off);
+create temp table primscanmarkcov_table(
+ a int,
+ b int
+);
+create index interesting_coverage_idx on primscanmarkcov_table(a, b) with (deduplicate_items = off);
+insert into outer_tab select 1, i from generate_series(1530, 1780) i;
+insert into primscanmarkcov_table select 1, i from generate_series(1530, 1780) i;
+insert into outer_tab select 1, 1550 from generate_series(1, 200) i;
+insert into primscanmarkcov_table select 1, 1551 from generate_series(1, 200) i;
+vacuum analyze outer_tab;
+vacuum analyze primscanmarkcov_table ;
+with range_ints as ( select i from generate_series(1530, 1780) i)
+select
+ count(*), buggy.a, buggy.b from
+outer_tab o
+ inner join
+primscanmarkcov_table buggy
+ on o.a = buggy.a and o.b = buggy.b
+where
+ o.a = 1 and o.b = any (array[(select array_agg(i) from range_ints where i % 50 = 0)]) and
+ buggy.a = 1 and buggy.b = any (array[(select array_agg(i) from range_ints where i % 50 = 0)])
+group by buggy.a, buggy.b
+order by buggy.a, buggy.b;
+ count | a | b
+-------+---+------
+ 201 | 1 | 1550
+ 1 | 1 | 1600
+ 1 | 1 | 1650
+ 1 | 1 | 1700
+ 1 | 1 | 1750
+(5 rows)
+
+-- Get test coverage for when so->needPrimScan is set at the point of calling
+-- _bt_restore_array_keys() for backwards scans. More or less comparable to
+-- the last test.
+create temp table backwards_prim_outer_table (a int, b int);
+create temp table backwards_restore_buggy_primscan_table (x int, y int);
+create index backward_prim_buggy_idx on backwards_restore_buggy_primscan_table (x, y) with (deduplicate_items=off);
+create index backwards_prim_drive_idx on backwards_prim_outer_table (a, b) with (deduplicate_items=off);
+insert into backwards_prim_outer_table select 0, 1360;
+insert into backwards_prim_outer_table select 1, b_vals from generate_series(1012, 1406) b_vals where b_vals % 10 = 0;
+insert into backwards_prim_outer_table select 1, 1370;
+vacuum analyze backwards_prim_outer_table; -- Be tidy
+-- Fill up "backwards_prim_drive_idx" index with 396 items, just about fitting
+-- onto its only page, which is a root leaf page:
+insert into backwards_restore_buggy_primscan_table select 0, 1360;
+insert into backwards_restore_buggy_primscan_table select 1, x_vals from generate_series(1012, 1406) x_vals;
+vacuum analyze backwards_restore_buggy_primscan_table; -- Be tidy
+-- Now cause two page splits, leaving 4 leaf pages in total:
+insert into backwards_restore_buggy_primscan_table select 1, 1370 from generate_series(1,250) i;
+-- Now "buggy" index looks like this:
+--
+-- ┌───┬───────┬───────┬────────┬────────┬────────────┬───────┬───────┬───────────────────┬─────────┬───────────┬──────────────────┐
+-- │ i │ blkno │ flags │ nhtids │ nhblks │ ndeadhblks │ nlive │ ndead │ nhtidschecksimple │ avgsize │ freespace │ highkey │
+-- ├───┼───────┼───────┼────────┼────────┼────────────┼───────┼───────┼───────────────────┼─────────┼───────────┼──────────────────┤
+-- │ 1 │ 1 │ 1 │ 203 │ 1 │ 0 │ 204 │ 0 │ 0 │ 16 │ 4,068 │ (x, y)=(1, 1214) │
+-- │ 2 │ 4 │ 1 │ 156 │ 2 │ 0 │ 157 │ 0 │ 0 │ 16 │ 5,008 │ (x, y)=(1, 1370) │
+-- │ 3 │ 5 │ 1 │ 251 │ 2 │ 0 │ 252 │ 0 │ 0 │ 16 │ 3,108 │ (x, y)=(1, 1371) │
+-- │ 4 │ 2 │ 1 │ 36 │ 1 │ 0 │ 36 │ 0 │ 0 │ 16 │ 7,428 │ ∅ │
+-- └───┴───────┴───────┴────────┴────────┴────────────┴───────┴───────┴───────────────────┴─────────┴───────────┴──────────────────┘
+select count(*), o.a, o.b
+ from
+ backwards_prim_outer_table o
+ inner join
+ backwards_restore_buggy_primscan_table bug
+ on o.a = bug.x and o.b = bug.y
+where
+ bug.x in (0, 1) and
+ bug.y = any(array[(select array_agg(i) from generate_series(1360, 1370) i where i % 10 = 0)])
+group by o.a, o.b
+order by o.a desc, o.b desc;
+ count | a | b
+-------+---+------
+ 502 | 1 | 1370
+ 1 | 1 | 1360
+ 1 | 0 | 1360
+(3 rows)
+
diff --git a/src/test/regress/expected/create_index.out b/src/test/regress/expected/create_index.out
index 446cfa678..b50409c7f 100644
--- a/src/test/regress/expected/create_index.out
+++ b/src/test/regress/expected/create_index.out
@@ -1910,7 +1910,7 @@ SELECT count(*) FROM dupindexcols
(1 row)
--
--- Check ordering of =ANY indexqual results (bug in 9.2.0)
+-- Check that index scans with =ANY indexquals return rows in index order
--
explain (costs off)
SELECT unique1 FROM tenk1
@@ -1936,12 +1936,11 @@ explain (costs off)
SELECT thousand, tenthous FROM tenk1
WHERE thousand < 2 AND tenthous IN (1001,3000)
ORDER BY thousand;
- QUERY PLAN
--------------------------------------------------------
+ QUERY PLAN
+--------------------------------------------------------------------------------
Index Only Scan using tenk1_thous_tenthous on tenk1
- Index Cond: (thousand < 2)
- Filter: (tenthous = ANY ('{1001,3000}'::integer[]))
-(3 rows)
+ Index Cond: ((thousand < 2) AND (tenthous = ANY ('{1001,3000}'::integer[])))
+(2 rows)
SELECT thousand, tenthous FROM tenk1
WHERE thousand < 2 AND tenthous IN (1001,3000)
@@ -1952,29 +1951,25 @@ ORDER BY thousand;
1 | 1001
(2 rows)
-SET enable_indexonlyscan = OFF;
explain (costs off)
SELECT thousand, tenthous FROM tenk1
WHERE thousand < 2 AND tenthous IN (1001,3000)
-ORDER BY thousand;
- QUERY PLAN
---------------------------------------------------------------------------------------
- Sort
- Sort Key: thousand
- -> Index Scan using tenk1_thous_tenthous on tenk1
- Index Cond: ((thousand < 2) AND (tenthous = ANY ('{1001,3000}'::integer[])))
-(4 rows)
+ORDER BY thousand DESC, tenthous DESC;
+ QUERY PLAN
+--------------------------------------------------------------------------------
+ Index Only Scan Backward using tenk1_thous_tenthous on tenk1
+ Index Cond: ((thousand < 2) AND (tenthous = ANY ('{1001,3000}'::integer[])))
+(2 rows)
SELECT thousand, tenthous FROM tenk1
WHERE thousand < 2 AND tenthous IN (1001,3000)
-ORDER BY thousand;
+ORDER BY thousand DESC, tenthous DESC;
thousand | tenthous
----------+----------
- 0 | 3000
1 | 1001
+ 0 | 3000
(2 rows)
-RESET enable_indexonlyscan;
--
-- Check elimination of constant-NULL subexpressions
--
diff --git a/src/test/regress/expected/join.out b/src/test/regress/expected/join.out
index 2c7327014..86e541780 100644
--- a/src/test/regress/expected/join.out
+++ b/src/test/regress/expected/join.out
@@ -8680,10 +8680,9 @@ where j1.id1 % 1000 = 1 and j2.id1 % 1000 = 1 and j2.id1 >= any (array[1,5]);
Merge Cond: (j1.id1 = j2.id1)
Join Filter: (j2.id2 = j1.id2)
-> Index Scan using j1_id1_idx on j1
- -> Index Only Scan using j2_pkey on j2
+ -> Index Scan using j2_id1_idx on j2
Index Cond: (id1 >= ANY ('{1,5}'::integer[]))
- Filter: ((id1 % 1000) = 1)
-(7 rows)
+(6 rows)
select * from j1
inner join j2 on j1.id1 = j2.id1 and j1.id2 = j2.id2
diff --git a/src/test/regress/sql/btree_index.sql b/src/test/regress/sql/btree_index.sql
index ef8435423..330edbb1d 100644
--- a/src/test/regress/sql/btree_index.sql
+++ b/src/test/regress/sql/btree_index.sql
@@ -267,3 +267,150 @@ CREATE TABLE btree_part (id int4) PARTITION BY RANGE (id);
CREATE INDEX btree_part_idx ON btree_part(id);
ALTER INDEX btree_part_idx ALTER COLUMN id SET (n_distinct=100);
DROP TABLE btree_part;
+
+-- Add tests to give coverage of various subtle issues.
+--
+-- XXX This may not be suitable for commit, due to taking up too many cycles.
+--
+-- Here we don't remember the scan's array keys before processing a page, only
+-- after processing a page (which is implicit, it's just the scan's current
+-- keys). So when we move the scan backwards we think that the top-level scan
+-- should terminate, when in reality it should jump backwards to the leaf page
+-- that we last visited.
+create temp table backup_wrong_tbl (district int4, warehouse int4, orderid int4, orderline int4);
+create index backup_wrong_idx on backup_wrong_tbl (district, warehouse, orderid, orderline);
+insert into backup_wrong_tbl
+select district, warehouse, orderid, orderline
+from
+ generate_series(1, 3) district,
+ generate_series(1, 2) warehouse,
+ generate_series(1, 51) orderid,
+ generate_series(1, 10) orderline;
+
+begin;
+declare back_up_terminate_toplevel_wrong cursor for
+select * from backup_wrong_tbl
+where district in (1, 3) and warehouse in (1,2)
+and orderid in (48, 50)
+order by district, warehouse, orderid, orderline;
+
+fetch forward 60 from back_up_terminate_toplevel_wrong;
+fetch backward 29 from back_up_terminate_toplevel_wrong;
+fetch forward 12 from back_up_terminate_toplevel_wrong;
+fetch backward 30 from back_up_terminate_toplevel_wrong;
+fetch forward 31 from back_up_terminate_toplevel_wrong;
+fetch backward 32 from back_up_terminate_toplevel_wrong;
+fetch forward 33 from back_up_terminate_toplevel_wrong;
+fetch backward 34 from back_up_terminate_toplevel_wrong;
+fetch forward 35 from back_up_terminate_toplevel_wrong;
+commit;
+
+create temp table outer_table (a int, b int);
+create temp table restore_buggy_primscan_table (x int, y int);
+
+create index buggy_idx on restore_buggy_primscan_table (x, y) with (deduplicate_items=off);
+
+insert into outer_table select 1, b_vals from generate_series(1006, 1580) b_vals;
+insert into restore_buggy_primscan_table select 1, x_vals from generate_series(1006, 1580) x_vals;
+
+insert into outer_table select 1, 1370 from generate_series(1, 9) j;
+insert into restore_buggy_primscan_table select 1, 1371 from generate_series(1, 9) j;
+insert into restore_buggy_primscan_table select 1, 1380 from generate_series(1, 9) j;
+
+vacuum analyze outer_table;
+vacuum analyze restore_buggy_primscan_table;
+
+select count(*), o.a, o.b
+ from
+ outer_table o
+ inner join
+ restore_buggy_primscan_table bug
+ on o.a = bug.x and o.b = bug.y
+where
+ bug.x = 1 and
+ bug.y = any(array[(select array_agg(i) from generate_series(1370, 1390) i where i % 10 = 0)])
+group by o.a, o.b;
+
+-- Get test coverage for when so->needPrimScan is set at the point of calling
+-- _bt_restore_array_keys(). This is handled like the case where the scan
+-- direction changes "within" a page, relying on code from _bt_readnextpage().
+create temp table outer_tab(
+ a int,
+ b int
+);
+create index outer_tab_idx on outer_tab(a, b) with (deduplicate_items = off);
+
+create temp table primscanmarkcov_table(
+ a int,
+ b int
+);
+create index interesting_coverage_idx on primscanmarkcov_table(a, b) with (deduplicate_items = off);
+
+insert into outer_tab select 1, i from generate_series(1530, 1780) i;
+insert into primscanmarkcov_table select 1, i from generate_series(1530, 1780) i;
+
+insert into outer_tab select 1, 1550 from generate_series(1, 200) i;
+insert into primscanmarkcov_table select 1, 1551 from generate_series(1, 200) i;
+
+vacuum analyze outer_tab;
+vacuum analyze primscanmarkcov_table ;
+
+with range_ints as ( select i from generate_series(1530, 1780) i)
+
+select
+ count(*), buggy.a, buggy.b from
+outer_tab o
+ inner join
+primscanmarkcov_table buggy
+ on o.a = buggy.a and o.b = buggy.b
+where
+ o.a = 1 and o.b = any (array[(select array_agg(i) from range_ints where i % 50 = 0)]) and
+ buggy.a = 1 and buggy.b = any (array[(select array_agg(i) from range_ints where i % 50 = 0)])
+group by buggy.a, buggy.b
+order by buggy.a, buggy.b;
+
+-- Get test coverage for when so->needPrimScan is set at the point of calling
+-- _bt_restore_array_keys() for backwards scans. More or less comparable to
+-- the last test.
+create temp table backwards_prim_outer_table (a int, b int);
+create temp table backwards_restore_buggy_primscan_table (x int, y int);
+
+create index backward_prim_buggy_idx on backwards_restore_buggy_primscan_table (x, y) with (deduplicate_items=off);
+create index backwards_prim_drive_idx on backwards_prim_outer_table (a, b) with (deduplicate_items=off);
+
+insert into backwards_prim_outer_table select 0, 1360;
+insert into backwards_prim_outer_table select 1, b_vals from generate_series(1012, 1406) b_vals where b_vals % 10 = 0;
+insert into backwards_prim_outer_table select 1, 1370;
+vacuum analyze backwards_prim_outer_table; -- Be tidy
+
+-- Fill up "backwards_prim_drive_idx" index with 396 items, just about fitting
+-- onto its only page, which is a root leaf page:
+insert into backwards_restore_buggy_primscan_table select 0, 1360;
+insert into backwards_restore_buggy_primscan_table select 1, x_vals from generate_series(1012, 1406) x_vals;
+vacuum analyze backwards_restore_buggy_primscan_table; -- Be tidy
+
+-- Now cause two page splits, leaving 4 leaf pages in total:
+insert into backwards_restore_buggy_primscan_table select 1, 1370 from generate_series(1,250) i;
+
+-- Now "buggy" index looks like this:
+--
+-- ┌───┬───────┬───────┬────────┬────────┬────────────┬───────┬───────┬───────────────────┬─────────┬───────────┬──────────────────┐
+-- │ i │ blkno │ flags │ nhtids │ nhblks │ ndeadhblks │ nlive │ ndead │ nhtidschecksimple │ avgsize │ freespace │ highkey │
+-- ├───┼───────┼───────┼────────┼────────┼────────────┼───────┼───────┼───────────────────┼─────────┼───────────┼──────────────────┤
+-- │ 1 │ 1 │ 1 │ 203 │ 1 │ 0 │ 204 │ 0 │ 0 │ 16 │ 4,068 │ (x, y)=(1, 1214) │
+-- │ 2 │ 4 │ 1 │ 156 │ 2 │ 0 │ 157 │ 0 │ 0 │ 16 │ 5,008 │ (x, y)=(1, 1370) │
+-- │ 3 │ 5 │ 1 │ 251 │ 2 │ 0 │ 252 │ 0 │ 0 │ 16 │ 3,108 │ (x, y)=(1, 1371) │
+-- │ 4 │ 2 │ 1 │ 36 │ 1 │ 0 │ 36 │ 0 │ 0 │ 16 │ 7,428 │ ∅ │
+-- └───┴───────┴───────┴────────┴────────┴────────────┴───────┴───────┴───────────────────┴─────────┴───────────┴──────────────────┘
+
+select count(*), o.a, o.b
+ from
+ backwards_prim_outer_table o
+ inner join
+ backwards_restore_buggy_primscan_table bug
+ on o.a = bug.x and o.b = bug.y
+where
+ bug.x in (0, 1) and
+ bug.y = any(array[(select array_agg(i) from generate_series(1360, 1370) i where i % 10 = 0)])
+group by o.a, o.b
+order by o.a desc, o.b desc;
diff --git a/src/test/regress/sql/create_index.sql b/src/test/regress/sql/create_index.sql
index d49ce9f30..9d68ef624 100644
--- a/src/test/regress/sql/create_index.sql
+++ b/src/test/regress/sql/create_index.sql
@@ -753,7 +753,7 @@ SELECT count(*) FROM dupindexcols
WHERE f1 BETWEEN 'WA' AND 'ZZZ' and id < 1000 and f1 ~<~ 'YX';
--
--- Check ordering of =ANY indexqual results (bug in 9.2.0)
+-- Check that index scans with =ANY indexquals return rows in index order
--
explain (costs off)
@@ -774,18 +774,14 @@ SELECT thousand, tenthous FROM tenk1
WHERE thousand < 2 AND tenthous IN (1001,3000)
ORDER BY thousand;
-SET enable_indexonlyscan = OFF;
-
explain (costs off)
SELECT thousand, tenthous FROM tenk1
WHERE thousand < 2 AND tenthous IN (1001,3000)
-ORDER BY thousand;
+ORDER BY thousand DESC, tenthous DESC;
SELECT thousand, tenthous FROM tenk1
WHERE thousand < 2 AND tenthous IN (1001,3000)
-ORDER BY thousand;
-
-RESET enable_indexonlyscan;
+ORDER BY thousand DESC, tenthous DESC;
--
-- Check elimination of constant-NULL subexpressions
--
2.43.0
^ permalink raw reply [nested|flat] 12+ messages in thread
end of thread, other threads:[~2023-12-09 18:38 UTC | newest]
Thread overview: 12+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2022-09-01 15:41 [PATCH] Fix FK name when colliding during partition attachment Jehan-Guillaume de Rorthais <[email protected]>
2023-11-07 12:20 Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan Matthias van de Meent <[email protected]>
2023-11-08 01:53 ` Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan Peter Geoghegan <[email protected]>
2023-11-09 23:57 ` Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan Peter Geoghegan <[email protected]>
2023-11-10 02:05 ` Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan Matthias van de Meent <[email protected]>
2023-11-11 21:08 ` Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan Matthias van de Meent <[email protected]>
2023-11-21 02:52 ` Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan Peter Geoghegan <[email protected]>
2023-11-27 13:39 ` Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan Heikki Linnakangas <[email protected]>
2023-12-05 03:25 ` Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan Peter Geoghegan <[email protected]>
2023-12-05 05:01 ` Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan Peter Geoghegan <[email protected]>
2023-11-28 12:29 ` Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan Tomas Vondra <[email protected]>
2023-12-09 18:38 ` Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan Peter Geoghegan <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox