From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: error context for vacuum to include block number |
Date: | 2019-12-15 13:07:08 |
Message-ID: | 20191215130708.GA19063@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Dec 13, 2019 at 04:47:35PM -0600, Justin Pryzby wrote:
> It's related code which I cleaned up before adding new stuff. Not essential,
> thus separate (0002 should be backpatched).
The issue just causes some extra work and that's not a bug, so applied
without a backpatch.
>> The refactoring in 0003 is interesting, so I would be tempted to merge
>> it. Now you have one small issue in it:
>> - /*
>> - * Forget the now-vacuumed tuples, and press on, but be careful
>> - * not to reset latestRemovedXid since we want that value to be
>> - * valid.
>> - */
>> + lazy_vacuum_heap_index(onerel, vacrelstats, Irel, nindexes, indstats);
>> vacrelstats->num_dead_tuples = 0;
>> - vacrelstats->num_index_scans++;
>> You are moving this comment within lazy_vacuum_heap_index, but it
>> applies to num_dead_tuples and not num_index_scans, no? You should
>> keep the incrementation of num_index_scans within the routine though.
>
> Thank you, fixed.
For 0003, I think that lazy_vacuum_heap_index() can be confusing as
those indexes are unrelated to heap. Why not naming it just
lazy_vacuum_all_indexes()? The routine should also have a header
describing it.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2019-12-15 16:06:39 | Re: more backtraces |
Previous Message | Andrey Lepikhov | 2019-12-15 10:56:44 | Re: Optimization of NestLoop join in the case of guaranteed empty inner subtree |