Re: Fast insertion indexes: why no developments

Jeff Janes <jeff(dot)janes(at)gmail(dot)com> writes:
> Robert removed the lmgr lock on the meta page by using a retry loop with
> lightweight locks. I've outlined how to remove the heavyweight lock on the
> bucket page as well, but it would require an on-disk change to the index so
> that each page knows how far the bucket it is in has been split, and it
> also might abuse the intention of lightweight locks a bit.

FWIW, I don't think that on-disk changes to hash indexes would be a
showstopper problem at this point. We could force people to reindex them
by means of changing the index version number on the metapage. The
reindex downtime would be annoying for production situations --- but given
the lack of WAL support, who'd be using one in production anyway?

> But I'm
> reluctant to put much time into that without there being any prospects of
> solving the problem of how to WAL bucket splits when buckets can have an
> unbounded number of overflow pages.

Agreed, if we don't see how to implement WAL logging then it's improbable
they'll ever get to production quality :-(.

ISTM the issue here is that we'd need to acknowledge incompletely-split
buckets as a valid state, no? But that could be a good thing anyway,
if it'd mean that we don't have to completely lock a bucket while
splitting it. All the other index types have comparable situations
where a maintenance operation might be only partly done.

Not that I'm volunteering to put any time into this myself.

regards, tom lane