On Fri, Aug 18, 2017 at 11:01 PM, Robert Haas <robertmh...@gmail.com> wrote:

> On Fri, Aug 18, 2017 at 1:12 PM, amul sul <sula...@gmail.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
the given argument type (i.e. array/range element type), and those hash
functions are made available in the TypeCacheEntry via lookup_type_cache().
in the hash_array & hash_range extended version requires a respective
hash function for those element type.

I have added hash_array_extended & hash_range_extended function in the
patch 0001, which maintains a local copy of TypeCacheEntry with extended
functions. But I am a little bit skeptic about this logic, any
​ ​
advice/suggestions will be
greatly appreciated.

The logic in the rest of the extended hash functions is same as the standard

​Attaching patch 0002​ for the reviewer's testing.


Attachment: 0001-add-optional-second-hash-proc-v2-wip.patch
Description: Binary data

Attachment: 0002-test-Hash_functions.patch
Description: Binary data

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to