Re: Microvacuum support for Hash Index
Ashutosh Sharma <ashu.coek88@gmail.com>
From: Ashutosh Sharma <ashu.coek88@gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2016-11-02T05:38:19Z
Lists: pgsql-hackers
Attachments
- microvacuum_hash_index_v2.patch (text/x-patch) patch v2
Hi, > While replaying the delete/vacuum record on standby, it can conflict > with some already running queries. Basically the replay can remove > some row which can be visible on standby. You need to resolve > conflicts similar to what we do in btree delete records (refer > btree_xlog_delete). Agreed. Thanks for putting this point. I have taken care of it in the attached v2 patch. > + /* > + * Write-lock the meta page so that we can decrement > + * tuple count. > + */ > + _hash_chgbufaccess(rel, metabuf, HASH_NOLOCK, HASH_WRITE); > + > + _hash_vacuum_one_page(rel, metabuf, buf, bucket_buf, > + (buf == bucket_buf) ? true : false); > + > + _hash_chgbufaccess(rel, metabuf, HASH_READ, HASH_NOLOCK); > > It seems here meta page lock is acquired for duration more than > required and also it is not required when there are no deletable items > on page. You can take the metapage lock before decrementing the count. Ok. Corrected. Please refer to the attached v2 patch. > Spurious space. There are some other similar spurious white space > changes in patch, remove them as well. Corrected. Please refer attached v2 patch.
Commits
-
Fixes for single-page hash index vacuum.
- 953477ca3526 10.0 landed
-
Port single-page btree vacuum logic to hash indexes.
- 6977b8b7f4df 10.0 landed
-
Avoid core dump for empty prepared statement in an aborted transaction.
- ba61a04bc7fe 10.0 cited
-
Change representation of statement lists, and add statement location info.
- ab1f0c822571 10.0 cited