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