> On Feb 14, 2020, at 8:29 AM, David Fetter <david@fetter.org> wrote:
>
> On Fri, Feb 14, 2020 at 08:16:47AM -0800, Mark Dilger wrote:
>>> On Feb 14, 2020, at 8:15 AM, David Fetter <david@fetter.org> wrote:
>>>
>>> On Fri, Feb 14, 2020 at 10:33:04AM -0500, Robert Haas wrote:
>>>> On Thu, Feb 13, 2020 at 11:26 AM Mark Dilger
>>>> <mark.dilger@enterprisedb.com> wrote:
>>>>> I have made these changes and rebased Robert’s patches but
>>>>> otherwise changed nothing. Here they are:
>>>>
>>>> Thanks. Anyone else have comments? I think this is pretty
>>>> straightforward and unobjectionable work so I'm inclined to press
>>>> forward with committing it fairly soon, but if someone feels
>>>> otherwise, please speak up.
>>>
>>> One question. It might be possible to make these functions faster
>>> using compiler intrinsics. Would those still be available to front-end
>>> code?
>>
>> Do you have a specific proposal that would preserve on-disk compatibility?
>
> I hadn't planned on changing the representation, just cutting
> instructions out of the calculation of same.
Ok, I misunderstood.
I thought the question was about using compiler intrinsics to implement an alltogether different hashing algorithm than
theone currently in use and whether exposing the hash function to frontend code would lock down the algorithm in a way
thatwould make it harder to change in the future. That lead me to the question of whether we had sufficient
flexibilityto entertain changing the hashing algorithm anyway.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
