Re: hash index concurrency

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, May 29, 2012 at 11:21 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
>> 2) Only support bitmap scans and not ordinary tid scans (the way gin
>> indexes already do).

> -1 on losing amgettuple. I regret that we lost that for GIN and I
> shall regret it more if we lose it anywhere else.

Not sure that's all that big a deal for hash. IIRC the only reasons to
want it are for index-only scans (not possible anyway with hash) and
exclusion constraints (for which you might as well use a btree, or plain
index-supported uniqueness if hash had that).

> But... even without doing either of the above, how about trying to
> eliminate the heavyweight locking around the metapage? I think the
> only reason we're using it there is for deadlock detection

I'm too lazy to go reread the README file, but my recollection is that
the potential deadlock is between different operations that're holding
locks on different buckets. It seems possible that we could use an
LWLock for the metapage while using heavyweight locks for buckets;
though it's not clear how much that buys us. But if you want to get rid
of heavyweight locks altogether, I think you have to do what Jeff said
and ditch amgettuple scans. The issue fundamentally is that if we
suspend an indexscan and return control to the executor while still
holding a lock, we risk deadlock because the executor could start up
some other scan that will want some other bucket lock, and meanwhile
some other backend could try to get the same two bucket locks in the
other order.

I guess another possibility would be to try to manage intra-bucket scans
similarly to the way btree does, where you stop "between" pages and
invent arcane page-splitting rules to ensure no loss of consistency.
Then maybe you don't need any lock while suspended; though it's not at
all clear how bucket splits could be allowed in such an environment.

regards, tom lane