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
-
Remove lsn from HashScanPosData.
- 22c5e73562c5 11.0 landed
-
Fix trivial mistake in README.
- 79a4a665c046 11.0 landed
-
hash: Implement page-at-a-time scan.
- 7c75ef571579 11.0 landed
-
Reduce pinning and buffer content locking for btree scans.
- 2ed5b87f96d4 9.5.0 cited