On Thu, Sep 21, 2017 at 3:08 AM, Ashutosh Sharma <ashu.coe...@gmail.com> wrote: > I have added a note for handling of logged and unlogged tables in > README file and also corrected the header comment for > hashbucketcleanup(). Please find the attached 0003*.patch having these > changes. Thanks.
I committed 0001 and 0002 with some additional edits as 7c75ef571579a3ad7a1d3ee909f11dba5e0b9440. I also rebased 0003 and edited it a bit; see attached hash-cleanup-changes.patch. I'm not entirely sold on 0003. An alternative would be to rip the lsn stuff back out of HashScanPosData, and I think we ought to consider that. Basically, 0003 is betting that getting rid of the lock-chaining in hash index vacuum is more valuable than being able to kill dead items more aggressively. I bet that's a bad bet. In the case of btree indexes, since 2ed5b87f96d473962ec5230fd820abfeaccb2069, page-at-a-time scanning allows most btree index scans to avoid holding buffer pins when the scan is suspended, but we gain no such advantage here. We always have to hold a pin on the primary bucket page anyway, so even with this patch cleanup is going to block when it hits a bucket containing a suspended scan. 0003 helps if (a) the relation is permanent, (b) the bucket has overflow pages, and (c) the scan is moving faster than vacuum and can overtake it instead of waiting. But that doesn't seem like it will happen very often at all, whereas the LSN check will probably fail frequently and cause us to skip cleanup that we could usefully have done. So I propose the attached hashscan-no-lsn.patch as an alternative. Thoughts? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
hash-cleanup-changes.patch
Description: Binary data
hashscan-no-lsn.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
