> On Feb 14, 2020, at 8:29 AM, David Fetter <da...@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 <da...@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.dil...@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 the one currently in use and
whether exposing the hash function to frontend code would lock down the
algorithm in a way that would make it harder to change in the future. That
lead me to the question of whether we had sufficient flexibility to entertain
changing the hashing algorithm anyway.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
