From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Greg Stark <gsstark(at)mit(dot)edu> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Preliminary notes about hash index concurrency (long) |
Date: | 2003-09-01 21:01:37 |
Message-ID: | 10525.1062450097@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greg Stark <gsstark(at)mit(dot)edu> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.
> 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?
Yes.
> 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?
Yes.
> 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?
AFAICS it's purely a performance issue.
Note also that a hash index will by definition have sucky performance on
large numbers of equal keys, so anyone who is using a hash index on such
a column deserves what they get. Now you could possibly have this
worst-case scenario even on a column with well-scattered keys, but it
seems improbable.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Lee Kindness | 2003-09-01 21:02:00 | Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...) |
Previous Message | Tommi Mäkitalo | 2003-09-01 21:01:25 | Re: TCP/IP with 7.4 beta2 broken? |