database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-03 20:02:46 +03:00
Code Activity

Improve performance of index-only scans with many index columns.

Browse Source 
StoreIndexTuple was a loop over index_getattr, which is O(N^2)
if the index columns are variable-width, and the performance
impact is already quite visible at ten columns.  The obvious
move is to replace that with a call to index_deform_tuple ...
but that's *also* a loop over index_getattr.  Improve it to
be essentially a clone of heap_deform_tuple.

(There are a few other places that loop over all index columns
with index_getattr, and perhaps should be changed likewise,
but most of them don't seem performance-critical.  Anyway, the
rest would mostly only be interested in the index key columns,
which there aren't likely to be so many of.  Wide index tuples
are a new thing with INCLUDE.)

Konstantin Knizhnik

Discussion: https://postgr.es/m/e06b2d27-04fc-5c0e-bb8c-ecd72aa24959@postgrespro.ru
This commit is contained in:
Tom Lane
2019-03-03 16:57:14 -05:00
parent 78b408a20a
commit 80b9e9c466
2 changed files with 72 additions and 17 deletions
Download Patch File Download Diff File Expand all files Collapse all files

20
src/backend/executor/nodeIndexonlyscan.c
View File

@ -269,23 +269,17 @@ IndexOnlyNext(IndexOnlyScanState *node)
static void
StoreIndexTuple(TupleTableSlot *slot, IndexTuple itup, TupleDesc itupdesc)
{
int nindexatts = itupdesc->natts;
Datum *values = slot->tts_values;
bool *isnull = slot->tts_isnull;
int i;
/*
* Note: we must use the tupdesc supplied by the AM in index_getattr, not
* the slot's tupdesc, in case the latter has different datatypes (this
* happens for btree name_ops in particular). They'd better have the same
* number of columns though, as well as being datatype-compatible which is
* something we can't so easily check.
* Note: we must use the tupdesc supplied by the AM in index_deform_tuple,
* not the slot's tupdesc, in case the latter has different datatypes
* (this happens for btree name_ops in particular). They'd better have
* the same number of columns though, as well as being datatype-compatible
* which is something we can't so easily check.
*/
Assert(slot->tts_tupleDescriptor->natts == nindexatts);
Assert(slot->tts_tupleDescriptor->natts == itupdesc->natts);
ExecClearTuple(slot);
for (i = 0; i < nindexatts; i++)
values[i] = index_getattr(itup, i + 1, itupdesc, &isnull[i]);
index_deform_tuple(itup, itupdesc, slot->tts_values, slot->tts_isnull);
ExecStoreVirtualTuple(slot);
}