Re: heapgettup refactoring
Melanie Plageman <melanieplageman@gmail.com>
From: Melanie Plageman <melanieplageman@gmail.com>
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: Andres Freund <andres@anarazel.de>,
Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2023-01-10T20:31:05Z
Lists: pgsql-hackers
Attachments
- v5-0003-Add-heapgettup_initial_block-helper.patch (text/x-patch) patch v5-0003
- v5-0001-pgindent-heapgettup-functions.patch (text/x-patch) patch v5-0001
- v5-0004-Streamline-heapgettup-for-refactor.patch (text/x-patch) patch v5-0004
- v5-0002-Add-no-movement-scan-helper.patch (text/x-patch) patch v5-0002
- v5-0005-Add-heapgettup-helpers.patch (text/x-patch) patch v5-0005
- v5-0007-Refactor-heapgettup-and-heapgettup_pagemode.patch (text/x-patch) patch v5-0007
- v5-0006-Add-heapgettup_advance_block-helper.patch (text/x-patch) patch v5-0006
On Thu, Jan 5, 2023 at 8:52 AM Peter Eisentraut
<peter.eisentraut@enterprisedb.com> wrote:
>
> Ok, let's look through these patches starting from the top then.
>
> v4-0001-Add-no-movement-scan-helper.patch
>
> This makes sense overall; there is clearly some duplicate code that can
> be unified.
>
> It appears that during your rebasing you have effectively reverted your
> earlier changes that have been committed as
> 8e1db29cdbbd218ab6ba53eea56624553c3bef8c. You should undo that.
Thanks. I think I have addressed this.
I've attached a rebased v5.
> I don't understand the purpose of the noinline maker. If it's not
> necessary to inline, we can just leave it off, but there is no need to
> outright prevent inlining AFAICT.
>
I have removed it.
> I don't know why you changed the if/else sequences. Before, the
> sequence was effectively
>
> if (forward)
> {
> ...
> }
> else if (backward)
> {
> ...
> }
> else
> {
> /* it's no movement */
> }
>
> Now it's changed to
>
> if (no movement)
> {
> ...
> return;
> }
>
> if (forward)
> {
> ...
> }
> else
> {
> Assert(backward);
> ...
> }
>
> Sure, that's the same thing, but it looks less elegant to me.
In this commit, you could keep the original ordering of if statements. I
preferred no movement scan first because then backwards and forwards
scans' code is physically closer to the rest of the code without the
intrusion of the no movement scan code.
Ultimately, the refactor (in later patches) flips the ordering of if
statements at the top from
if (scan direction)
to
if (initial or continue)
and this isn't a very interesting distinction for no movement scans. By
dealing with no movement scan at the top, I didn't have to handle no
movement scans in the initial and continue branches in the new structure.
Also, I will note that patches 4-6 at least and perhaps 4-7 do not make
sense as separate commits. I separated them for ease of review. Each is
correct and passes tests but is not really an improvement without the
others.
- Melanie
Commits
-
Remove stray duplicated comment in heapam.h
- 9ed50ab3496f 16.0 landed
-
More refactoring of heapgettup() and heapgettup_pagemode()
- cfcf56f92398 16.0 landed
-
Run pgindent on heapam.c
- 009dbdea02d7 16.0 landed
-
Push lpp variable closer to usage in heapgetpage()
- e351f8541831 16.0 landed
-
Variable renaming in preparation for refactoring
- 8e1db29cdbbd 16.0 landed
-
Turn HeapKeyTest macro into inline function
- 4eb3b1120001 16.0 landed
-
Remove unused include
- c0f1e51ac79e 16.0 landed
-
Remove redundant breaks in HeapTupleSatisfiesVisibility
- c3652cd84ac8 16.0 landed