Re: GUC for cleanup indexes threshold.

From: Kuntal Ghosh <kuntalghosh(dot)2007(at)gmail(dot)com>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: GUC for cleanup indexes threshold.
Date: 2017-02-10 11:01:21
Message-ID: CAGz5QCKvWwEjV7gb55Xkxjv0JRhHcPF=+XB0DUoHqXVRaJdwpQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jan 4, 2017 at 1:51 PM, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:

> Attached patch introduces new GUC parameter parameter
> vacuum_cleanup_index_scale_factor which specifies the fraction of the
> table pages containing dead tuple needed to trigger a cleaning up
> indexes. The default is 0.0, which means that the cleanup index is not
> invoked if no update on table. In other word, if table is completely
> frozen then lazy vacuum can skip the index scans as well. Increasing
> this value could reduce total time of lazy vacuum but the statistics
> and the free space map of index are not updated.
>
I was looking into your patch and trying to understand how the
following piece of code works.
+ if (vacuumed_pages > cleanupidx_thresh)
+ {
+ for (i = 0; i < nindexes; i++)
+ lazy_cleanup_index(Irel[i], indstats[i], vacrelstats);
+ }
So, you are skipping deletion of index entries if it does not reach
the clean-up index threshold. But, you are removing all dead tuples
from the heap pointed by the same index. Hence, index will contain
entries with invalid references. How does that work? How will you
remove those index entries later? (I'm a newbie.)

+ This parameter can only be set anywhere.
Oxymoron. :-)

--
Thanks & Regards,
Kuntal Ghosh
EnterpriseDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2017-02-10 11:04:08 Re: parallelize queries containing initplans
Previous Message Simon Riggs 2017-02-10 10:19:58 Re: Documentation improvements for partitioning