Hi,
I could see some diff getting generated after running pgindent script
on 'src/backend/access/hash/hashpage.c' file and from the diff it
looks like it got introduced as a part of this commit. Below is the
diff observed,
/*
* If possible, clean up the old bucket. We might not be able
to do this
* if someone else has a pin on it, but if not then we can go
ahead. This
- * isn't absolutely necessary, but it reduces bloat; if we
don't do it now,
- * VACUUM will do it eventually, but maybe not until new overflow pages
- * have been allocated. Note that there's no need to clean up the new
- * bucket.
+ * isn't absolutely necessary, but it reduces bloat; if we don't do it
+ * now, VACUUM will do it eventually, but maybe not until new overflow
+ * pages have been allocated. Note that there's no need to clean up the
+ * new bucket.
*/
--
With Regards,
Ashutosh Sharma
EnterpriseDB:http://www.enterprisedb.com
On Sat, Aug 5, 2017 at 6:24 AM, Robert Haas <rhaas@postgresql.org> wrote:
> hash: Immediately after a bucket split, try to clean the old bucket.
>
> If it works, then we won't be storing two copies of all the tuples
> that were just moved. If not, VACUUM will still take care of it
> eventually. Per a report from AP and analysis from Amit Kapila, it
> seems that a bulk load can cause splits fast enough that VACUUM won't
> deal with the problem in time to prevent bloat.
>
> Amit Kapila; I rewrote the comment.
>
> Discussion: http://postgr.es/m/20170704105728.mwb72jebfmok2nm2@zip.com.au
>
> Branch
> ------
> master
>
> Details
> -------
> https://git.postgresql.org/pg/commitdiff/ff98a5e1e49de061600feb6b4de5ce0a22d386af
>
> Modified Files
> --------------
> src/backend/access/hash/hashpage.c | 45 ++++++++++++++++++++++++++++----------
> 1 file changed, 34 insertions(+), 11 deletions(-)
>
>
> --
> Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-committers