Re: [PROPOSAL] VACUUM Progress Checker.

From: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
To: Amit Langote <amitlangote09(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: "Thakur, Sameer" <Sameer(dot)Thakur(at)nttdata(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PROPOSAL] VACUUM Progress Checker.
Date: 2015-07-22 15:23:28
Message-ID: 55AFB570.4050808@BlueTreble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 7/22/15 6:58 AM, Amit Langote wrote:
> On Wed, Jul 22, 2015 at 8:19 PM, Alvaro Herrera
> <alvherre(at)2ndquadrant(dot)com> wrote:
>>
>> Not sure what Jim meant. Maybe he meant to be aware of when spilling to
>> disk happens? Obviously, things become slower, so maybe you need to
>> consider it for progress reporting purposes.
>>
>
> Perhaps the m_w_m determines how many dead tuples lazy_scan_heap() can
> keep track of before doing a lazy_vacuum_indexes() +
> lazy_vacuum_heap() round. Smaller the m_w_m, more the number of index
> scans, slower the progress?

Yes. Any percent completion calculation will have to account for the
case of needing multiple passes through all the indexes.

Each dead tuple requires 6 bytes (IIRC) of maintenance work mem. So if
you're deleting 5M rows with m_w_m=1MB you should be getting many passes
through the indexes. Studying the output of VACUUM VERBOSE will confirm
that (or just throw a temporary WARNING in the path where we start the
scan).
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Data in Trouble? Get it in Treble! http://BlueTreble.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Nasby 2015-07-22 15:28:56 Re: [PROPOSAL] VACUUM Progress Checker.
Previous Message YANG 2015-07-22 15:16:08 Queries runs slow on GPU with PG-Strom