Re: Polyphase merge is obsolete

From: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, John Naylor <john(dot)naylor(at)enterprisedb(dot)com>
Cc: Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>, vignesh C <vignesh21(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Peter Geoghegan <pg(at)bowt(dot)ie>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Zhihong Yu <zyu(at)yugabyte(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>
Subject: Re: Polyphase merge is obsolete
Date: 2022-11-21 09:29:52
Message-ID: 57ab1e04-215d-f342-f04e-67097f3acc66@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 21.11.22 00:57, Heikki Linnakangas wrote:
> On 19/11/2022 13:00, Peter Eisentraut wrote:
>> On 18.10.21 14:15, Heikki Linnakangas wrote:
>>> On 05/10/2021 20:24, John Naylor wrote:
>>>> I've had a chance to review and test out the v5 patches.
>>>
>>> Thanks! I fixed the stray reference to PostgreSQL 14 that Zhihong
>>> mentioned, and pushed.
>>
>> AFAICT, this thread updated the API of LogicalTapeSetCreate() in PG15,
>> but did not adequately update the function header comment.  The comment
>> still mentions the "shared" argument, which has been removed.  There is
>> a new "preallocate" argument that is not mentioned at all.  Also, it's
>> not easy to match the actual callers to the call variants described in
>> the comment.  Could someone who remembers this work perhaps look this
>> over and update the comment?
>
> Is the attached more readable?

That looks better, thanks.

> I'm not 100% sure of the "preallocate" argument. If I understand
> correctly, you should pass true if you are writing multiple tapes at the
> same time, and false otherwise. HashAgg passed true, tuplesort passes
> false. However, it's not clear to me why we couldn't just always do the
> preallocation. It seems pretty harmless even if it's not helpful. Or do
> it when there are multiple writer tapes, and not otherwise. The
> parameter was added in commit 0758964963 so presumably there was a
> reason, but at a quick glance at the thread that led to that commit, I
> couldn't see what it was.

Right, these are the kinds of questions such a comment ought to answer.

Let's see if anyone chimes in here, otherwise let's complain in the
original thread, since it had nothing to do with this one.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message John Naylor 2022-11-21 09:30:29 Re: [PoC] Improve dead tuple storage for lazy vacuum
Previous Message Aleksander Alekseev 2022-11-21 09:21:09 Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)