database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-11 10:01:57 +03:00
Code Activity

Install a search tree depth limit in GIN bulk-insert operations, to prevent

Browse Source 
them from degrading badly when the input is sorted or nearly so.  In this
scenario the tree is unbalanced to the point of becoming a mere linked list,
so insertions become O(N^2).  The easiest and most safely back-patchable
solution is to stop growing the tree sooner, ie limit the growth of N.  We
might later consider a rebalancing tree algorithm, but it's not clear that
the benefit would be worth the cost and complexity.  Per report from Sergey
Burladyan and an earlier complaint from Heikki.

Back-patch to 8.2; older versions didn't have GIN indexes.
This commit is contained in:
Tom Lane
2009-03-24 22:06:03 +00:00
parent fc022d72c7
commit e5efda442c
3 changed files with 20 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
src/backend/access/gin/ginfast.c
View File

@ -11,7 +11,7 @@
* Portions Copyright (c) 1994, Regents of the University of California
*
* IDENTIFICATION
* $PostgreSQL: pgsql/src/backend/access/gin/ginfast.c,v 1.1 2009/03/24 20:17:10 tgl Exp $
* $PostgreSQL: pgsql/src/backend/access/gin/ginfast.c,v 1.2 2009/03/24 22:06:03 tgl Exp $
*
*-------------------------------------------------------------------------
*/
@ -749,9 +749,10 @@ ginInsertCleanup(Relation index, GinState *ginstate,
* XXX using up maintenance_work_mem here is probably unreasonably
* much, since vacuum might already be using that much.
*/
if ( GinPageGetOpaque(page)->rightlink == InvalidBlockNumber ||
( GinPageHasFullRow(page) &&
accum.allocatedMemory > maintenance_work_mem * 1024L ) )
if (GinPageGetOpaque(page)->rightlink == InvalidBlockNumber ||
(GinPageHasFullRow(page) &&
(accum.allocatedMemory >= maintenance_work_mem * 1024L ||
accum.maxdepth > GIN_MAX_TREE_DEPTH)))
{
ItemPointerData *list;
uint32 nlist;