1
0
mirror of https://github.com/postgres/postgres.git synced 2025-07-28 23:42:10 +03:00

Adjust btree index build to not use shared buffers, thereby avoiding the

locking conflict against concurrent CHECKPOINT that was discussed a few
weeks ago.  Also, if not using WAL archiving (which is always true ATM
but won't be if PITR makes it into this release), there's no need to
WAL-log the index build process; it's sufficient to force-fsync the
completed index before commit.  This seems to gain about a factor of 2
in my tests, which is consistent with writing half as much data.  I did
not try it with WAL on a separate drive though --- probably the gain would
be a lot less in that scenario.
This commit is contained in:
Tom Lane
2004-06-02 17:28:18 +00:00
parent 4d0e47d5a9
commit 2095206de1
8 changed files with 304 additions and 214 deletions

View File

@ -12,7 +12,7 @@
* Portions Copyright (c) 1994, Regents of the University of California
*
* IDENTIFICATION
* $PostgreSQL: pgsql/src/backend/access/nbtree/nbtree.c,v 1.116 2004/05/31 19:24:04 tgl Exp $
* $PostgreSQL: pgsql/src/backend/access/nbtree/nbtree.c,v 1.117 2004/06/02 17:28:17 tgl Exp $
*
*-------------------------------------------------------------------------
*/
@ -112,10 +112,6 @@ btbuild(PG_FUNCTION_ARGS)
elog(ERROR, "index \"%s\" already contains data",
RelationGetRelationName(index));
/* initialize the btree index metadata page */
/* mark it valid right away only if using slow build */
_bt_metapinit(index, !buildstate.usefast);
if (buildstate.usefast)
{
buildstate.spool = _bt_spoolinit(index, indexInfo->ii_Unique, false);
@ -127,6 +123,11 @@ btbuild(PG_FUNCTION_ARGS)
if (indexInfo->ii_Unique)
buildstate.spool2 = _bt_spoolinit(index, false, true);
}
else
{
/* if using slow build, initialize the btree index metadata page */
_bt_metapinit(index);
}
/* do the heap scan */
reltuples = IndexBuildHeapScan(heap, index, indexInfo,