From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Usage of epoch in txid_current |
Date: | 2018-07-16 13:55:48 |
Message-ID: | 18412.1531749348@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2018-07-15 16:41:35 -0400, Tom Lane wrote:
>> Andres Freund <andres(at)anarazel(dot)de> writes:
>>> On 2018-07-09 19:56:25 -0400, Tom Lane wrote:
>>>> Or, perhaps, use a struct in assert builds and int64 otherwise?
>>>> You could hide the ensuing notational differences in macros.
>> [ bunch of test results ]
>> Offhand it would seem that we can get away with struct wrappers
>> on any platform where performance is really of concern today.
> Cool, thanks for checking!
BTW, independently of any performance questions, these results show
that my idea above was untenable anyway. On those platforms where
there is a codegen difference, doing it like that would have resulted
in an ABI difference between regular and assert builds. That's something
to avoid, at least in any API that's visible to extension modules ---
we've had project policy for some time that it should be possible to
use non-assert extensions with assert-enabled core and vice versa.
Conceivably we could have used the struct API only under a special
devel flag that few people use except a buildfarm animal or two.
But that's just a pain in the rear.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-07-16 14:12:48 | Re: patch to allow disable of WAL recycling |
Previous Message | Andres Freund | 2018-07-16 13:44:53 | Re: Pluggable Storage - Andres's take |