Re: README of hash index

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: README of hash index
Date: 2016-09-16 16:26:59
Message-ID: CAMkU=1zTNn8Yrj2rN1P-J1=aMFNW-NK4OVpqxnhgS2APnd9hVQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Sep 16, 2016 at 4:20 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
wrote:

> Currently README of hash module contain algorithms written in below form.
>
> The insertion algorithm is rather similar:
>
> pin meta page and take buffer content lock in shared mode
> loop:
> compute bucket number for target hash key
> release meta page buffer content lock
> if (correct bucket page is already locked)
> break
> release any existing bucket page lock (if a concurrent split happened)
> take heavyweight bucket lock in shared mode
> retake meta page buffer content lock in shared mode
> -- (so far same as reader)
> release pin on metapage
> ..
> ..
>
> I have mostly updated them in the patches I have proposed to improve
> hash index. However, each time I try to update them, I find that it
> is easy to follow the code than to read and understand the existing
> algorithm written in above form from README.
>
> Do others find it useful to maintain the algorithms in above form?
>

I think that having them all condensed into one place makes it easier to
think through the locking models to decide if there might be races or
deadlocks. If you only care about the algorithm for inserting in
isolation, I agree reading the code might be better.

But the use of white space isn't always consistent, and I don't know what a
double hyphen means. I think it could use improvement, rather than
abolishing.

Cheers,

Jeff

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Artur Zakirov 2016-09-16 16:31:40 Re: Bug in to_timestamp().
Previous Message Sachin Kotwal 2016-09-16 16:26:39 Re: Why postgres take RowExclusiveLock on all partition