Re: Cleanup - Removed unused function parameter in reorder buffer & parallel vacuum

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Cleanup - Removed unused function parameter in reorder buffer & parallel vacuum
Date: 2020-07-03 13:52:19
Message-ID: 929783.1593784339@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> writes:
> On Fri, Jul 3, 2020 at 2:06 PM Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> Seems like a change with low utility.

> Yeah, all or most of the ReorderBuffer APIs seem to take the
> "ReorderBuffer *" parameter, so not sure if removing from some of them
> is useful or not. At least in the current form, they look consistent.

Yeah, I agree with that. This makes things less consistent and it seems
like it's not buying much. Are any of these code paths sufficiently hot
that saving a couple of instructions would matter?

In the long run, it seems like the fact that any of these functions
are not using these parameters is an implementation artifact that
could change at any time. So we might just be putting them back
someday, with nothing except code churn and back-patch hazards to
show for our trouble. Or, if you want to argue that a "ReorderBufferXXX"
function is inherently never going to use the ReorderBuffer, why is it
in that module with that name to begin with?

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Adam Brusselback 2020-07-03 13:57:55 Re: Persist MVCC forever - retain history
Previous Message Tom Lane 2020-07-03 13:45:31 Re: Missing "Up" navigation link between parts and doc root?