| 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 18:39:18 |
| Message-ID: | 20191104183918.crxwzbfpr6ps7peh@development |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Nov 04, 2019 at 10:04:09AM -0800, Andres Freund wrote:
>Hi,
>
>(I've not read the rest of this thread yet)
>
>On 2019-11-04 16:07:23 +0100, Tomas Vondra wrote:
>> On Mon, Nov 04, 2019 at 04:39:44PM +0300, Павел Ерёмин wrote:
>> > And yet, if I try to implement a similar mechanism, if successful, will my
>> > revision be considered?
>> >
>>
>> Why wouldn't it be considered? If you submit a patch that demonstrably
>> improves the behavior (in this case reduces per-tuple overhead without
>> causing significant issues elsewhere), we'd be crazy not to consider it.
>
>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 ...
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2019-11-04 18:44:53 | Re: 64 bit transaction id |
| Previous Message | Andres Freund | 2019-11-04 18:28:29 | Re: cost based vacuum (parallel) |