2011-12-17 16:41:16 -05:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
|
|
|
* spginsert.c
|
|
|
|
* Externally visible index creation/insertion routines
|
|
|
|
*
|
|
|
|
* All the actual insertion logic is in spgdoinsert.c.
|
|
|
|
*
|
2023-01-02 15:00:37 -05:00
|
|
|
* Portions Copyright (c) 1996-2023, PostgreSQL Global Development Group
|
2011-12-17 16:41:16 -05:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
|
|
|
*
|
|
|
|
* IDENTIFICATION
|
|
|
|
* src/backend/access/spgist/spginsert.c
|
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "postgres.h"
|
|
|
|
|
2019-12-27 08:09:00 +09:00
|
|
|
#include "access/genam.h"
|
2011-12-17 16:41:16 -05:00
|
|
|
#include "access/spgist_private.h"
|
2017-02-14 15:37:59 -05:00
|
|
|
#include "access/spgxlog.h"
|
2019-03-27 19:59:06 -07:00
|
|
|
#include "access/tableam.h"
|
2014-11-06 13:52:08 +02:00
|
|
|
#include "access/xlog.h"
|
|
|
|
#include "access/xloginsert.h"
|
2011-12-17 16:41:16 -05:00
|
|
|
#include "catalog/index.h"
|
|
|
|
#include "miscadmin.h"
|
|
|
|
#include "storage/bufmgr.h"
|
|
|
|
#include "storage/smgr.h"
|
|
|
|
#include "utils/memutils.h"
|
2012-08-31 17:04:31 -04:00
|
|
|
#include "utils/rel.h"
|
2011-12-17 16:41:16 -05:00
|
|
|
|
|
|
|
|
|
|
|
typedef struct
|
|
|
|
{
|
|
|
|
SpGistState spgstate; /* SPGiST's working state */
|
2018-03-22 13:23:47 -04:00
|
|
|
int64 indtuples; /* total number of tuples indexed */
|
2011-12-17 16:41:16 -05:00
|
|
|
MemoryContext tmpCtx; /* per-tuple temporary context */
|
|
|
|
} SpGistBuildState;
|
|
|
|
|
|
|
|
|
2019-03-27 19:59:06 -07:00
|
|
|
/* Callback to process one heap tuple during table_index_build_scan */
|
2011-12-17 16:41:16 -05:00
|
|
|
static void
|
2019-11-08 00:44:52 -08:00
|
|
|
spgistBuildCallback(Relation index, ItemPointer tid, Datum *values,
|
2011-12-17 16:41:16 -05:00
|
|
|
bool *isnull, bool tupleIsAlive, void *state)
|
|
|
|
{
|
|
|
|
SpGistBuildState *buildstate = (SpGistBuildState *) state;
|
2012-03-11 16:29:04 -04:00
|
|
|
MemoryContext oldCtx;
|
2011-12-17 16:41:16 -05:00
|
|
|
|
2012-03-11 16:29:04 -04:00
|
|
|
/* Work in temp context, and reset it after each tuple */
|
|
|
|
oldCtx = MemoryContextSwitchTo(buildstate->tmpCtx);
|
2011-12-17 16:41:16 -05:00
|
|
|
|
2013-11-02 16:45:42 -04:00
|
|
|
/*
|
|
|
|
* Even though no concurrent insertions can be happening, we still might
|
|
|
|
* get a buffer-locking failure due to bgwriter or checkpointer taking a
|
|
|
|
* lock on some buffer. So we need to be willing to retry. We can flush
|
|
|
|
* any temp data when retrying.
|
|
|
|
*/
|
2019-11-08 00:44:52 -08:00
|
|
|
while (!spgdoinsert(index, &buildstate->spgstate, tid,
|
2021-04-05 18:41:09 -04:00
|
|
|
values, isnull))
|
2013-11-02 16:45:42 -04:00
|
|
|
{
|
|
|
|
MemoryContextReset(buildstate->tmpCtx);
|
|
|
|
}
|
2011-12-17 16:41:16 -05:00
|
|
|
|
2018-03-22 13:23:47 -04:00
|
|
|
/* Update total tuple count */
|
|
|
|
buildstate->indtuples += 1;
|
|
|
|
|
2012-03-11 16:29:04 -04:00
|
|
|
MemoryContextSwitchTo(oldCtx);
|
|
|
|
MemoryContextReset(buildstate->tmpCtx);
|
2011-12-17 16:41:16 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Build an SP-GiST index.
|
|
|
|
*/
|
Restructure index access method API to hide most of it at the C level.
This patch reduces pg_am to just two columns, a name and a handler
function. All the data formerly obtained from pg_am is now provided
in a C struct returned by the handler function. This is similar to
the designs we've adopted for FDWs and tablesample methods. There
are multiple advantages. For one, the index AM's support functions
are now simple C functions, making them faster to call and much less
error-prone, since the C compiler can now check function signatures.
For another, this will make it far more practical to define index access
methods in installable extensions.
A disadvantage is that SQL-level code can no longer see attributes
of index AMs; in particular, some of the crosschecks in the opr_sanity
regression test are no longer possible from SQL. We've addressed that
by adding a facility for the index AM to perform such checks instead.
(Much more could be done in that line, but for now we're content if the
amvalidate functions more or less replace what opr_sanity used to do.)
We might also want to expose some sort of reporting functionality, but
this patch doesn't do that.
Alexander Korotkov, reviewed by Petr Jelínek, and rather heavily
editorialized on by me.
2016-01-17 19:36:59 -05:00
|
|
|
IndexBuildResult *
|
|
|
|
spgbuild(Relation heap, Relation index, IndexInfo *indexInfo)
|
2011-12-17 16:41:16 -05:00
|
|
|
{
|
|
|
|
IndexBuildResult *result;
|
|
|
|
double reltuples;
|
|
|
|
SpGistBuildState buildstate;
|
|
|
|
Buffer metabuffer,
|
2012-03-11 16:29:04 -04:00
|
|
|
rootbuffer,
|
|
|
|
nullbuffer;
|
2011-12-17 16:41:16 -05:00
|
|
|
|
|
|
|
if (RelationGetNumberOfBlocks(index) != 0)
|
|
|
|
elog(ERROR, "index \"%s\" already contains data",
|
|
|
|
RelationGetRelationName(index));
|
|
|
|
|
|
|
|
/*
|
2012-03-11 16:29:04 -04:00
|
|
|
* Initialize the meta page and root pages
|
2011-12-17 16:41:16 -05:00
|
|
|
*/
|
|
|
|
metabuffer = SpGistNewBuffer(index);
|
|
|
|
rootbuffer = SpGistNewBuffer(index);
|
2012-03-11 16:29:04 -04:00
|
|
|
nullbuffer = SpGistNewBuffer(index);
|
2011-12-17 16:41:16 -05:00
|
|
|
|
|
|
|
Assert(BufferGetBlockNumber(metabuffer) == SPGIST_METAPAGE_BLKNO);
|
2012-03-11 16:29:04 -04:00
|
|
|
Assert(BufferGetBlockNumber(rootbuffer) == SPGIST_ROOT_BLKNO);
|
|
|
|
Assert(BufferGetBlockNumber(nullbuffer) == SPGIST_NULL_BLKNO);
|
2011-12-17 16:41:16 -05:00
|
|
|
|
|
|
|
START_CRIT_SECTION();
|
|
|
|
|
2016-04-20 08:31:19 -05:00
|
|
|
SpGistInitMetapage(BufferGetPage(metabuffer));
|
2011-12-17 16:41:16 -05:00
|
|
|
MarkBufferDirty(metabuffer);
|
|
|
|
SpGistInitBuffer(rootbuffer, SPGIST_LEAF);
|
|
|
|
MarkBufferDirty(rootbuffer);
|
2012-03-11 16:29:04 -04:00
|
|
|
SpGistInitBuffer(nullbuffer, SPGIST_LEAF | SPGIST_NULLS);
|
|
|
|
MarkBufferDirty(nullbuffer);
|
2011-12-17 16:41:16 -05:00
|
|
|
|
|
|
|
|
|
|
|
END_CRIT_SECTION();
|
|
|
|
|
|
|
|
UnlockReleaseBuffer(metabuffer);
|
|
|
|
UnlockReleaseBuffer(rootbuffer);
|
2012-03-11 16:29:04 -04:00
|
|
|
UnlockReleaseBuffer(nullbuffer);
|
2011-12-17 16:41:16 -05:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Now insert all the heap data into the index
|
|
|
|
*/
|
|
|
|
initSpGistState(&buildstate.spgstate, index);
|
|
|
|
buildstate.spgstate.isBuild = true;
|
2018-03-22 13:23:47 -04:00
|
|
|
buildstate.indtuples = 0;
|
2011-12-17 16:41:16 -05:00
|
|
|
|
|
|
|
buildstate.tmpCtx = AllocSetContextCreate(CurrentMemoryContext,
|
|
|
|
"SP-GiST build temporary context",
|
Add macros to make AllocSetContextCreate() calls simpler and safer.
I found that half a dozen (nearly 5%) of our AllocSetContextCreate calls
had typos in the context-sizing parameters. While none of these led to
especially significant problems, they did create minor inefficiencies,
and it's now clear that expecting people to copy-and-paste those calls
accurately is not a great idea. Let's reduce the risk of future errors
by introducing single macros that encapsulate the common use-cases.
Three such macros are enough to cover all but two special-purpose contexts;
those two calls can be left as-is, I think.
While this patch doesn't in itself improve matters for third-party
extensions, it doesn't break anything for them either, and they can
gradually adopt the simplified notation over time.
In passing, change TopMemoryContext to use the default allocation
parameters. Formerly it could only be extended 8K at a time. That was
probably reasonable when this code was written; but nowadays we create
many more contexts than we did then, so that it's not unusual to have a
couple hundred K in TopMemoryContext, even without considering various
dubious code that sticks other things there. There seems no good reason
not to let it use growing blocks like most other contexts.
Back-patch to 9.6, mostly because that's still close enough to HEAD that
it's easy to do so, and keeping the branches in sync can be expected to
avoid some future back-patching pain. The bugs fixed by these changes
don't seem to be significant enough to justify fixing them further back.
Discussion: <21072.1472321324@sss.pgh.pa.us>
2016-08-27 17:50:38 -04:00
|
|
|
ALLOCSET_DEFAULT_SIZES);
|
2011-12-17 16:41:16 -05:00
|
|
|
|
Report progress of CREATE INDEX operations
This uses the progress reporting infrastructure added by c16dc1aca5e0,
adding support for CREATE INDEX and CREATE INDEX CONCURRENTLY.
There are two pieces to this: one is index-AM-agnostic, and the other is
AM-specific. The latter is fairly elaborate for btrees, including
reportage for parallel index builds and the separate phases that btree
index creation uses; other index AMs, which are much simpler in their
building procedures, have simplistic reporting only, but that seems
sufficient, at least for non-concurrent builds.
The index-AM-agnostic part is fairly complete, providing insight into
the CONCURRENTLY wait phases as well as block-based progress during the
index validation table scan. (The index validation index scan requires
patching each AM, which has not been included here.)
Reviewers: Rahila Syed, Pavan Deolasee, Tatsuro Yamada
Discussion: https://postgr.es/m/20181220220022.mg63bhk26zdpvmcj@alvherre.pgsql
2019-04-02 15:18:08 -03:00
|
|
|
reltuples = table_index_build_scan(heap, index, indexInfo, true, true,
|
2019-03-27 19:59:06 -07:00
|
|
|
spgistBuildCallback, (void *) &buildstate,
|
|
|
|
NULL);
|
2011-12-17 16:41:16 -05:00
|
|
|
|
|
|
|
MemoryContextDelete(buildstate.tmpCtx);
|
|
|
|
|
|
|
|
SpGistUpdateMetaPage(index);
|
|
|
|
|
Generate less WAL during GiST, GIN and SP-GiST index build.
Instead of WAL-logging every modification during the build separately,
first build the index without any WAL-logging, and make a separate pass
through the index at the end, to write all pages to the WAL. This
significantly reduces the amount of WAL generated, and is usually also
faster, despite the extra I/O needed for the extra scan through the index.
WAL generated this way is also faster to replay.
For GiST, the LSN-NSN interlock makes this a little tricky. All pages must
be marked with a valid (i.e. non-zero) LSN, so that the parent-child
LSN-NSN interlock works correctly. We now use magic value 1 for that during
index build. Change the fake LSN counter to begin from 1000, so that 1 is
safely smaller than any real or fake LSN. 2 would've been enough for our
purposes, but let's reserve a bigger range, in case we need more special
values in the future.
Author: Anastasia Lubennikova, Andrey V. Lepikhov
Reviewed-by: Heikki Linnakangas, Dmitry Dolgov
2019-04-03 17:03:15 +03:00
|
|
|
/*
|
|
|
|
* We didn't write WAL records as we built the index, so if WAL-logging is
|
|
|
|
* required, write all pages to the WAL now.
|
|
|
|
*/
|
|
|
|
if (RelationNeedsWAL(index))
|
|
|
|
{
|
|
|
|
log_newpage_range(index, MAIN_FORKNUM,
|
|
|
|
0, RelationGetNumberOfBlocks(index),
|
|
|
|
true);
|
|
|
|
}
|
|
|
|
|
2011-12-17 16:41:16 -05:00
|
|
|
result = (IndexBuildResult *) palloc0(sizeof(IndexBuildResult));
|
2018-03-22 13:23:47 -04:00
|
|
|
result->heap_tuples = reltuples;
|
|
|
|
result->index_tuples = buildstate.indtuples;
|
2011-12-17 16:41:16 -05:00
|
|
|
|
Restructure index access method API to hide most of it at the C level.
This patch reduces pg_am to just two columns, a name and a handler
function. All the data formerly obtained from pg_am is now provided
in a C struct returned by the handler function. This is similar to
the designs we've adopted for FDWs and tablesample methods. There
are multiple advantages. For one, the index AM's support functions
are now simple C functions, making them faster to call and much less
error-prone, since the C compiler can now check function signatures.
For another, this will make it far more practical to define index access
methods in installable extensions.
A disadvantage is that SQL-level code can no longer see attributes
of index AMs; in particular, some of the crosschecks in the opr_sanity
regression test are no longer possible from SQL. We've addressed that
by adding a facility for the index AM to perform such checks instead.
(Much more could be done in that line, but for now we're content if the
amvalidate functions more or less replace what opr_sanity used to do.)
We might also want to expose some sort of reporting functionality, but
this patch doesn't do that.
Alexander Korotkov, reviewed by Petr Jelínek, and rather heavily
editorialized on by me.
2016-01-17 19:36:59 -05:00
|
|
|
return result;
|
2011-12-17 16:41:16 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Build an empty SPGiST index in the initialization fork
|
|
|
|
*/
|
Restructure index access method API to hide most of it at the C level.
This patch reduces pg_am to just two columns, a name and a handler
function. All the data formerly obtained from pg_am is now provided
in a C struct returned by the handler function. This is similar to
the designs we've adopted for FDWs and tablesample methods. There
are multiple advantages. For one, the index AM's support functions
are now simple C functions, making them faster to call and much less
error-prone, since the C compiler can now check function signatures.
For another, this will make it far more practical to define index access
methods in installable extensions.
A disadvantage is that SQL-level code can no longer see attributes
of index AMs; in particular, some of the crosschecks in the opr_sanity
regression test are no longer possible from SQL. We've addressed that
by adding a facility for the index AM to perform such checks instead.
(Much more could be done in that line, but for now we're content if the
amvalidate functions more or less replace what opr_sanity used to do.)
We might also want to expose some sort of reporting functionality, but
this patch doesn't do that.
Alexander Korotkov, reviewed by Petr Jelínek, and rather heavily
editorialized on by me.
2016-01-17 19:36:59 -05:00
|
|
|
void
|
|
|
|
spgbuildempty(Relation index)
|
2011-12-17 16:41:16 -05:00
|
|
|
{
|
Use the buffer cache when initializing an unlogged index.
Some of the ambuildempty functions used smgrwrite() directly, followed
by smgrimmedsync(). A few small problems with that:
Firstly, one is supposed to use smgrextend() when extending a
relation, not smgrwrite(). It doesn't make much difference in
production builds. smgrextend() updates the relation size cache, so
you miss that, but that's harmless because we never use the cached
relation size of an init fork. But if you compile with
CHECK_WRITE_VS_EXTEND, you get an assertion failure.
Secondly, the smgrwrite() calls were performed before WAL-logging, so
the page image written to disk had 0/0 as the LSN, not the LSN of the
WAL record. That's also harmless in practice, but seems sloppy.
Thirdly, it's better to use the buffer cache, because then you don't
need to smgrimmedsync() the relation to disk, which adds latency.
Bypassing the cache makes sense for bulk operations like index
creation, but not when you're just initializing an empty index.
Creation of unlogged tables is hardly performance bottleneck in any
real world applications, but nevertheless.
Backpatch to v16, but no further. These issues should be harmless in
practice, so better to not rock the boat in older branches.
Reviewed-by: Robert Haas
Discussion: https://www.postgresql.org/message-id/6e5bbc08-cdfc-b2b3-9e23-1a914b9850a9@iki.fi
2023-08-23 17:21:31 +03:00
|
|
|
Buffer metabuffer,
|
|
|
|
rootbuffer,
|
|
|
|
nullbuffer;
|
2011-12-17 16:41:16 -05:00
|
|
|
|
2016-12-08 14:09:09 -05:00
|
|
|
/*
|
Use the buffer cache when initializing an unlogged index.
Some of the ambuildempty functions used smgrwrite() directly, followed
by smgrimmedsync(). A few small problems with that:
Firstly, one is supposed to use smgrextend() when extending a
relation, not smgrwrite(). It doesn't make much difference in
production builds. smgrextend() updates the relation size cache, so
you miss that, but that's harmless because we never use the cached
relation size of an init fork. But if you compile with
CHECK_WRITE_VS_EXTEND, you get an assertion failure.
Secondly, the smgrwrite() calls were performed before WAL-logging, so
the page image written to disk had 0/0 as the LSN, not the LSN of the
WAL record. That's also harmless in practice, but seems sloppy.
Thirdly, it's better to use the buffer cache, because then you don't
need to smgrimmedsync() the relation to disk, which adds latency.
Bypassing the cache makes sense for bulk operations like index
creation, but not when you're just initializing an empty index.
Creation of unlogged tables is hardly performance bottleneck in any
real world applications, but nevertheless.
Backpatch to v16, but no further. These issues should be harmless in
practice, so better to not rock the boat in older branches.
Reviewed-by: Robert Haas
Discussion: https://www.postgresql.org/message-id/6e5bbc08-cdfc-b2b3-9e23-1a914b9850a9@iki.fi
2023-08-23 17:21:31 +03:00
|
|
|
* Initialize the meta page and root pages
|
2016-12-08 14:09:09 -05:00
|
|
|
*/
|
Use the buffer cache when initializing an unlogged index.
Some of the ambuildempty functions used smgrwrite() directly, followed
by smgrimmedsync(). A few small problems with that:
Firstly, one is supposed to use smgrextend() when extending a
relation, not smgrwrite(). It doesn't make much difference in
production builds. smgrextend() updates the relation size cache, so
you miss that, but that's harmless because we never use the cached
relation size of an init fork. But if you compile with
CHECK_WRITE_VS_EXTEND, you get an assertion failure.
Secondly, the smgrwrite() calls were performed before WAL-logging, so
the page image written to disk had 0/0 as the LSN, not the LSN of the
WAL record. That's also harmless in practice, but seems sloppy.
Thirdly, it's better to use the buffer cache, because then you don't
need to smgrimmedsync() the relation to disk, which adds latency.
Bypassing the cache makes sense for bulk operations like index
creation, but not when you're just initializing an empty index.
Creation of unlogged tables is hardly performance bottleneck in any
real world applications, but nevertheless.
Backpatch to v16, but no further. These issues should be harmless in
practice, so better to not rock the boat in older branches.
Reviewed-by: Robert Haas
Discussion: https://www.postgresql.org/message-id/6e5bbc08-cdfc-b2b3-9e23-1a914b9850a9@iki.fi
2023-08-23 17:21:31 +03:00
|
|
|
metabuffer = ReadBufferExtended(index, INIT_FORKNUM, P_NEW, RBM_NORMAL, NULL);
|
|
|
|
LockBuffer(metabuffer, BUFFER_LOCK_EXCLUSIVE);
|
|
|
|
rootbuffer = ReadBufferExtended(index, INIT_FORKNUM, P_NEW, RBM_NORMAL, NULL);
|
|
|
|
LockBuffer(rootbuffer, BUFFER_LOCK_EXCLUSIVE);
|
|
|
|
nullbuffer = ReadBufferExtended(index, INIT_FORKNUM, P_NEW, RBM_NORMAL, NULL);
|
|
|
|
LockBuffer(nullbuffer, BUFFER_LOCK_EXCLUSIVE);
|
2011-12-17 16:41:16 -05:00
|
|
|
|
Use the buffer cache when initializing an unlogged index.
Some of the ambuildempty functions used smgrwrite() directly, followed
by smgrimmedsync(). A few small problems with that:
Firstly, one is supposed to use smgrextend() when extending a
relation, not smgrwrite(). It doesn't make much difference in
production builds. smgrextend() updates the relation size cache, so
you miss that, but that's harmless because we never use the cached
relation size of an init fork. But if you compile with
CHECK_WRITE_VS_EXTEND, you get an assertion failure.
Secondly, the smgrwrite() calls were performed before WAL-logging, so
the page image written to disk had 0/0 as the LSN, not the LSN of the
WAL record. That's also harmless in practice, but seems sloppy.
Thirdly, it's better to use the buffer cache, because then you don't
need to smgrimmedsync() the relation to disk, which adds latency.
Bypassing the cache makes sense for bulk operations like index
creation, but not when you're just initializing an empty index.
Creation of unlogged tables is hardly performance bottleneck in any
real world applications, but nevertheless.
Backpatch to v16, but no further. These issues should be harmless in
practice, so better to not rock the boat in older branches.
Reviewed-by: Robert Haas
Discussion: https://www.postgresql.org/message-id/6e5bbc08-cdfc-b2b3-9e23-1a914b9850a9@iki.fi
2023-08-23 17:21:31 +03:00
|
|
|
Assert(BufferGetBlockNumber(metabuffer) == SPGIST_METAPAGE_BLKNO);
|
|
|
|
Assert(BufferGetBlockNumber(rootbuffer) == SPGIST_ROOT_BLKNO);
|
|
|
|
Assert(BufferGetBlockNumber(nullbuffer) == SPGIST_NULL_BLKNO);
|
|
|
|
|
|
|
|
START_CRIT_SECTION();
|
|
|
|
|
|
|
|
SpGistInitMetapage(BufferGetPage(metabuffer));
|
|
|
|
MarkBufferDirty(metabuffer);
|
|
|
|
SpGistInitBuffer(rootbuffer, SPGIST_LEAF);
|
|
|
|
MarkBufferDirty(rootbuffer);
|
|
|
|
SpGistInitBuffer(nullbuffer, SPGIST_LEAF | SPGIST_NULLS);
|
|
|
|
MarkBufferDirty(nullbuffer);
|
|
|
|
|
|
|
|
log_newpage_buffer(metabuffer, true);
|
|
|
|
log_newpage_buffer(rootbuffer, true);
|
|
|
|
log_newpage_buffer(nullbuffer, true);
|
|
|
|
|
|
|
|
END_CRIT_SECTION();
|
|
|
|
|
|
|
|
UnlockReleaseBuffer(metabuffer);
|
|
|
|
UnlockReleaseBuffer(rootbuffer);
|
|
|
|
UnlockReleaseBuffer(nullbuffer);
|
2011-12-17 16:41:16 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Insert one new tuple into an SPGiST index.
|
|
|
|
*/
|
Restructure index access method API to hide most of it at the C level.
This patch reduces pg_am to just two columns, a name and a handler
function. All the data formerly obtained from pg_am is now provided
in a C struct returned by the handler function. This is similar to
the designs we've adopted for FDWs and tablesample methods. There
are multiple advantages. For one, the index AM's support functions
are now simple C functions, making them faster to call and much less
error-prone, since the C compiler can now check function signatures.
For another, this will make it far more practical to define index access
methods in installable extensions.
A disadvantage is that SQL-level code can no longer see attributes
of index AMs; in particular, some of the crosschecks in the opr_sanity
regression test are no longer possible from SQL. We've addressed that
by adding a facility for the index AM to perform such checks instead.
(Much more could be done in that line, but for now we're content if the
amvalidate functions more or less replace what opr_sanity used to do.)
We might also want to expose some sort of reporting functionality, but
this patch doesn't do that.
Alexander Korotkov, reviewed by Petr Jelínek, and rather heavily
editorialized on by me.
2016-01-17 19:36:59 -05:00
|
|
|
bool
|
|
|
|
spginsert(Relation index, Datum *values, bool *isnull,
|
|
|
|
ItemPointer ht_ctid, Relation heapRel,
|
Allow index AMs to cache data across aminsert calls within a SQL command.
It's always been possible for index AMs to cache data across successive
amgettuple calls within a single SQL command: the IndexScanDesc.opaque
field is meant for precisely that. However, no comparable facility
exists for amortizing setup work across successive aminsert calls.
This patch adds such a feature and teaches GIN, GIST, and BRIN to use it
to amortize catalog lookups they'd previously been doing on every call.
(The other standard index AMs keep everything they need in the relcache,
so there's little to improve there.)
For GIN, the overall improvement in a statement that inserts many rows
can be as much as 10%, though it seems a bit less for the other two.
In addition, this makes a really significant difference in runtime
for CLOBBER_CACHE_ALWAYS tests, since in those builds the repeated
catalog lookups are vastly more expensive.
The reason this has been hard up to now is that the aminsert function is
not passed any useful place to cache per-statement data. What I chose to
do is to add suitable fields to struct IndexInfo and pass that to aminsert.
That's not widening the index AM API very much because IndexInfo is already
within the ken of ambuild; in fact, by passing the same info to aminsert
as to ambuild, this is really removing an inconsistency in the AM API.
Discussion: https://postgr.es/m/27568.1486508680@sss.pgh.pa.us
2017-02-09 11:52:12 -05:00
|
|
|
IndexUniqueCheck checkUnique,
|
2021-01-13 08:11:00 -08:00
|
|
|
bool indexUnchanged,
|
Allow index AMs to cache data across aminsert calls within a SQL command.
It's always been possible for index AMs to cache data across successive
amgettuple calls within a single SQL command: the IndexScanDesc.opaque
field is meant for precisely that. However, no comparable facility
exists for amortizing setup work across successive aminsert calls.
This patch adds such a feature and teaches GIN, GIST, and BRIN to use it
to amortize catalog lookups they'd previously been doing on every call.
(The other standard index AMs keep everything they need in the relcache,
so there's little to improve there.)
For GIN, the overall improvement in a statement that inserts many rows
can be as much as 10%, though it seems a bit less for the other two.
In addition, this makes a really significant difference in runtime
for CLOBBER_CACHE_ALWAYS tests, since in those builds the repeated
catalog lookups are vastly more expensive.
The reason this has been hard up to now is that the aminsert function is
not passed any useful place to cache per-statement data. What I chose to
do is to add suitable fields to struct IndexInfo and pass that to aminsert.
That's not widening the index AM API very much because IndexInfo is already
within the ken of ambuild; in fact, by passing the same info to aminsert
as to ambuild, this is really removing an inconsistency in the AM API.
Discussion: https://postgr.es/m/27568.1486508680@sss.pgh.pa.us
2017-02-09 11:52:12 -05:00
|
|
|
IndexInfo *indexInfo)
|
2011-12-17 16:41:16 -05:00
|
|
|
{
|
|
|
|
SpGistState spgstate;
|
|
|
|
MemoryContext oldCtx;
|
|
|
|
MemoryContext insertCtx;
|
|
|
|
|
|
|
|
insertCtx = AllocSetContextCreate(CurrentMemoryContext,
|
|
|
|
"SP-GiST insert temporary context",
|
Add macros to make AllocSetContextCreate() calls simpler and safer.
I found that half a dozen (nearly 5%) of our AllocSetContextCreate calls
had typos in the context-sizing parameters. While none of these led to
especially significant problems, they did create minor inefficiencies,
and it's now clear that expecting people to copy-and-paste those calls
accurately is not a great idea. Let's reduce the risk of future errors
by introducing single macros that encapsulate the common use-cases.
Three such macros are enough to cover all but two special-purpose contexts;
those two calls can be left as-is, I think.
While this patch doesn't in itself improve matters for third-party
extensions, it doesn't break anything for them either, and they can
gradually adopt the simplified notation over time.
In passing, change TopMemoryContext to use the default allocation
parameters. Formerly it could only be extended 8K at a time. That was
probably reasonable when this code was written; but nowadays we create
many more contexts than we did then, so that it's not unusual to have a
couple hundred K in TopMemoryContext, even without considering various
dubious code that sticks other things there. There seems no good reason
not to let it use growing blocks like most other contexts.
Back-patch to 9.6, mostly because that's still close enough to HEAD that
it's easy to do so, and keeping the branches in sync can be expected to
avoid some future back-patching pain. The bugs fixed by these changes
don't seem to be significant enough to justify fixing them further back.
Discussion: <21072.1472321324@sss.pgh.pa.us>
2016-08-27 17:50:38 -04:00
|
|
|
ALLOCSET_DEFAULT_SIZES);
|
2011-12-17 16:41:16 -05:00
|
|
|
oldCtx = MemoryContextSwitchTo(insertCtx);
|
|
|
|
|
|
|
|
initSpGistState(&spgstate, index);
|
|
|
|
|
2013-06-14 14:26:43 -04:00
|
|
|
/*
|
|
|
|
* We might have to repeat spgdoinsert() multiple times, if conflicts
|
|
|
|
* occur with concurrent insertions. If so, reset the insertCtx each time
|
|
|
|
* to avoid cumulative memory consumption. That means we also have to
|
|
|
|
* redo initSpGistState(), but it's cheap enough not to matter.
|
|
|
|
*/
|
2021-04-05 18:41:09 -04:00
|
|
|
while (!spgdoinsert(index, &spgstate, ht_ctid, values, isnull))
|
2013-06-14 14:26:43 -04:00
|
|
|
{
|
|
|
|
MemoryContextReset(insertCtx);
|
|
|
|
initSpGistState(&spgstate, index);
|
|
|
|
}
|
2011-12-17 16:41:16 -05:00
|
|
|
|
|
|
|
SpGistUpdateMetaPage(index);
|
|
|
|
|
|
|
|
MemoryContextSwitchTo(oldCtx);
|
|
|
|
MemoryContextDelete(insertCtx);
|
|
|
|
|
|
|
|
/* return false since we've not done any unique check */
|
Restructure index access method API to hide most of it at the C level.
This patch reduces pg_am to just two columns, a name and a handler
function. All the data formerly obtained from pg_am is now provided
in a C struct returned by the handler function. This is similar to
the designs we've adopted for FDWs and tablesample methods. There
are multiple advantages. For one, the index AM's support functions
are now simple C functions, making them faster to call and much less
error-prone, since the C compiler can now check function signatures.
For another, this will make it far more practical to define index access
methods in installable extensions.
A disadvantage is that SQL-level code can no longer see attributes
of index AMs; in particular, some of the crosschecks in the opr_sanity
regression test are no longer possible from SQL. We've addressed that
by adding a facility for the index AM to perform such checks instead.
(Much more could be done in that line, but for now we're content if the
amvalidate functions more or less replace what opr_sanity used to do.)
We might also want to expose some sort of reporting functionality, but
this patch doesn't do that.
Alexander Korotkov, reviewed by Petr Jelínek, and rather heavily
editorialized on by me.
2016-01-17 19:36:59 -05:00
|
|
|
return false;
|
2011-12-17 16:41:16 -05:00
|
|
|
}
|