On Thu, Sep 15, 2016 at 2:13 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: > One other point, I would like to discuss is that currently, we have a > concept for tracking active hash scans (hashscan.c) which I think is > mainly to protect splits when the backend which is trying to split has > some scan open. You can read "Other Notes" section of > access/hash/README for further details. I think after this patch we > don't need that mechanism for splits because we always retain a pin on > bucket buffer till all the tuples are fetched or scan is finished > which will defend against a split by our own backend which tries to > ensure cleanup lock on bucket.
Hmm, yeah. It seems like we can remove it. > However, we might need it for vacuum > (hashbulkdelete), if we want to get rid of cleanup lock in vacuum, > once we have a page-at-a-time scan mode implemented for hash indexes. > If you agree with above analysis, then we can remove the checks for > _hash_has_active_scan from both vacuum and split path and also remove > corresponding code from hashbegin/end scan, but retain that hashscan.c > for future improvements. Do you have a plan for that? I'd be inclined to just blow away hashscan.c if we don't need it any more, unless you're pretty sure it's going to get reused. It's not like we can't pull it back out of git if we decide we want it back after all. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
