Re: Preliminary notes about hash index concurrency (long) - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Preliminary notes about hash index concurrency (long)
Date
Msg-id 873cfgh7mb.fsf@stark.dyndns.tv
Whole thread Raw
In response to Preliminary notes about hash index concurrency (long)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Preliminary notes about hash index concurrency (long)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:

> If multiple inserters failed to split, the index might still be overfull,
> but eventually, the index will not be overfull and split attempts will stop.
> (We could make a successful splitter loop to see if the index is still
> overfull, but I think I prefer distributing the split overhead across
> successive insertions.)

If one backend is executing a query but the client has paused reading records,
is it possible the shared lock on the index bucket would be held for a long
time?

If so wouldn't it be possible for an arbitrarily large number of records to be
inserted while the lock is held, eventually causing the bucket to become
extremely large? Is there a maximum size at which the bucket split MUST
succeed or is it purely a performance issue that the buckets be reasonably
balanced?

-- 
greg



pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
Next
From: Pavel Stehule
Date:
Subject: array constructor can't construct empty array