Re: int8/float8/time/timestamp[tz]/float4 passed by value, was Re: Fix HAVE_LONG[_LONG]_INT_64 to really define to 1 - Mailing list pgsql-patches

From Zoltan Boszormenyi
Subject Re: int8/float8/time/timestamp[tz]/float4 passed by value, was Re: Fix HAVE_LONG[_LONG]_INT_64 to really define to 1
Date
Msg-id 47E835F9.8040804@cybertec.at
Whole thread Raw
In response to Re: int8/float8/time/timestamp[tz]/float4 passed by value, was Re: Fix HAVE_LONG[_LONG]_INT_64 to really define to 1  (Gregory Stark <stark@enterprisedb.com>)
Responses Re: int8/float8/time/timestamp[tz]/float4 passed by value, was Re: Fix HAVE_LONG[_LONG]_INT_64 to really define to 1
List pgsql-patches
Hi,

Gregory Stark írta:
> "Zoltan Boszormenyi" <zb@cybertec.at> writes:
>
>
>> - the int8inc(), int2_sum() and int4_sum() used pointers directly from the
>> Datums
>>  for performance, that code path is now commented out, the other code path
>>  is correct for the AggState and !AggState runs and correct every time and now
>>  because of the passbyval nature of int8, the !AggState version is not slower
>>  than using the pointer directly.
>>
>
> Does this mean count() and sum() are slower on a 32-bit machine?
>

If you mean "slower than on a 64-bit machine" then yes.
If you mean "slower than before", then no. I didn't express myself
correctly.
The original code path is not commented out, it is just conditionally
compiled.

BTW I found the tsearch bug, it was a missing conversion of float4
in gistproc.c, it was an unfortunate detail that this didn't cause a
segfault,
it woul have been easier to find. Now there are no failing regression tests.

--
----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
http://www.postgresql.at/


Attachment

pgsql-patches by date:

Previous
From: Gregory Stark
Date:
Subject: Re: int8/float8/time/timestamp[tz]/float4 passed by value, was Re: Fix HAVE_LONG[_LONG]_INT_64 to really define to 1
Next
From: Gregory Stark
Date:
Subject: Re: int8/float8/time/timestamp[tz]/float4 passed by value, was Re: Fix HAVE_LONG[_LONG]_INT_64 to really define to 1