From: | amul sul <sulamul(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, Joe Conway <mail(at)joeconway(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Jeff Davis <pgsql(at)j-davis(dot)com>, Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp> |
Subject: | Re: Hash Functions |
Date: | 2017-08-29 07:32:03 |
Message-ID: | CAAJ_b95KqMsDda6CU9Op6n2S0s-vAmjg_Z3pEBDfmdtAN3QrcA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Aug 22, 2017 at 5:44 PM, amul sul <sulamul(at)gmail(dot)com> wrote:
> On Fri, Aug 18, 2017 at 11:01 PM, Robert Haas <robertmhaas(at)gmail(dot)com>
> wrote:
>
>> On Fri, Aug 18, 2017 at 1:12 PM, amul sul <sulamul(at)gmail(dot)com> wrote:
>> > I have a small query, what if I want a cache entry with extended hash
>> > function instead standard one, I might require that while adding
>> > hash_array_extended function? Do you think we need to extend
>> > lookup_type_cache() as well?
>>
>> Hmm, I thought you had changed the hash partitioning stuff so that it
>> didn't rely on lookup_type_cache(). You have to look up the function
>> using the opclass provided in the partition key definition;
>> lookup_type_cache() will give you the default one for the datatype.
>> Maybe just use get_opfamily_proc?
>>
>>
> Yes, we can do that for
> the
> partitioning code, but my concern is a little bit
> different. I apologize, I wasn't clear enough.
>
> I am trying to extend hash_array & hash_range function. The hash_array and
> hash_range function calculates hash by using the respective hash function
> for
> the given argument type (i.e. array/range element type), and those hash
> functions are made available in the TypeCacheEntry via
> lookup_type_cache(). But
> in the hash_array & hash_range extended version requires a respective
> extended
> hash function for those element type.
>
> I have added hash_array_extended & hash_range_extended function in the
> attached
> patch 0001, which maintains a local copy of TypeCacheEntry with extended
> hash
> functions. But I am a little bit skeptic about this logic, any
>
> advice/suggestions will be
> greatly appreciated.
>
>
Instead, in the attached patch, I have modified lookup_type_cache() to
request it to get extended hash function in the TypeCacheEntry.
For that, I've introduced new flags as TYPECACHE_HASH_EXTENDED_PROC,
TYPECACHE_HASH_EXTENDED_PROC_FINFO & TCFLAGS_CHECKED_HASH_EXTENDED_PROC, and
additional variables in TypeCacheEntry structure to hold extended hash proc
information.
> The logic in the rest of the extended hash functions is same as the
> standard
> one.
>
Same for the hash_array_extended() & hash_range_extended() function as
well.
Regards,
Amul
Attachment | Content-Type | Size |
---|---|---|
0001-add-optional-second-hash-proc-v2.patch | application/octet-stream | 64.9 KB |
0002-test-Hash_functions_wip.patch | application/octet-stream | 13.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Ryan Murphy | 2017-08-29 07:32:46 | Re: assorted code cleanup |
Previous Message | Masahiko Sawada | 2017-08-29 07:25:55 | Re: Quorum commit for multiple synchronous replication. |