Re: 64 bit transaction id

From: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Павел Ерёмин <shnoor111gmail(at)yandex(dot)ru>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: 64 bit transaction id
Date: 2019-11-04 19:44:55
Message-ID: 20191104194455.rcmdbytofjejhq3m@development
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Nov 04, 2019 at 10:44:53AM -0800, Andres Freund wrote:
>Hi,
>
>On 2019-11-04 19:39:18 +0100, Tomas Vondra wrote:
>> On Mon, Nov 04, 2019 at 10:04:09AM -0800, Andres Freund wrote:
>> > And "without causing significant issues elsewhere" unfortunately
>> > includes continuing to allow pg_upgrade to work.
>
>> Yeah. I suppose we could have a different AM implementing this, but
>> maybe that's not possible ...
>
>Entirely possible. But the amount of code duplication / unnecessary
>branching and the user confusion from two very similar AMs, would have
>to be weighed against the benefits.
>

Agreed. I think code complexity is part of the trade-off. IMO it's fine
to hack existing heap AM initially, and only explore the separate AM if
that turns out to be promising.

regards

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2019-11-04 19:52:14 Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.
Previous Message Alvaro Herrera 2019-11-04 19:44:19 Re: v12 and pg_restore -f-