Re: Hash Indexes - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Hash Indexes
Date
Msg-id CAA4eK1KjvjxQJNsZ7cwq64VisT263t2AbDop6TOzQMSkwtfEmg@mail.gmail.com
Whole thread Raw
In response to Re: Hash Indexes  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Hash Indexes  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
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.  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.

I am posting this as a separate mail to avoid it getting lost as one
of the points in long list of review points discussed.

Thoughts?

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



pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: Printing bitmap objects in the debugger
Next
From: Ashutosh Bapat
Date:
Subject: Re: Printing bitmap objects in the debugger