Re: Hash Indexes

On Mon, Oct 10, 2016 at 5:55 AM, Amit Kapila <amit.kapila16@gmail.com>
wrote:

> On Thu, Sep 29, 2016 at 8:27 PM, Amit Kapila <amit.kapila16@gmail.com>
> wrote:
> > On Thu, Sep 29, 2016 at 6:04 AM, Robert Haas <robertmhaas@gmail.com>
> wrote:
> >
> >> Another thing I don't quite understand about this algorithm is that in
> >> order to conditionally lock the target primary bucket page, we'd first
> >> need to read and pin it.  And that doesn't seem like a good thing to
> >> do while we're holding a shared content lock on the metapage, because
> >> of the principle that we don't want to hold content locks across I/O.
> >>
> >
>
> Aren't we already doing this during BufferAlloc() when the buffer
> selected by StrategyGetBuffer() is dirty?
>

Right, you probably shouldn't allocate another buffer while holding a
content lock on a different one, if you can help it. But, BufferAlloc
doesn't do that internally, does it?  It is only a problem if you make it
be one by the way you use it.  Am I missing something?


>
> > I think we can release metapage content lock before reading the buffer.
> >
>
> On thinking about this again, if we release the metapage content lock
> before reading and pinning the primary bucket page, then we need to
> take it again to verify if the split has happened during the time we
> don't have a lock on a metapage.  Releasing and again taking content
> lock on metapage is not
> good from the performance aspect.  Do you have some other idea for this?
>

Doesn't the relcache patch effectively deal wit hthis?  If this is a
sticking point, maybe the relcache patch could be incorporated into this
one.

Cheers,

Jeff