Обсуждение: [COMMITTERS] pgsql: hash: Immediately after a bucket split,try to clean the old buc

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(-)

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