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