Re: Page Scan Mode in Hash Index

Amit Kapila <amit.kapila16@gmail.com>

From: Amit Kapila <amit.kapila16@gmail.com>
To: Ashutosh Sharma <ashu.coek88@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Jesper Pedersen <jesper.pedersen@redhat.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2017-04-04T10:29:05Z
Lists: pgsql-hackers
On Mon, Mar 27, 2017 at 7:04 PM, Ashutosh Sharma <ashu.coek88@gmail.com> wrote:
>
> My guess (which could be wrong) is that so->hashso_bucket_buf =
>> InvalidBuffer should be moved back up higher in the function where it
>> was before, just after the first if statement, and that the new
>> condition so->hashso_bucket_buf == so->currPos.buf on the last
>> _hash_dropbuf() should be removed.  If that's not right, then I think
>> I need somebody to explain why not.
>
> Okay, as i mentioned above, in case of page scan mode we only keep pin
> on a bucket buf. There won't be any case where we will be having pin
> on overflow buf at the end of scan.
>

What if mark the buffer as invalid after releasing the pin?  We are
already doing it that way in btree code, refer
_bt_drop_lock_and_maybe_pin().  I think if we do that way, then we can
do what Robert is suggesting.

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com


Commits

  1. Remove lsn from HashScanPosData.

  2. Fix trivial mistake in README.

  3. hash: Implement page-at-a-time scan.

  4. Reduce pinning and buffer content locking for btree scans.