Re: Postgres 11, partitioning with a custom hash function

From: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
To: Harry B <harrysungod(at)gmail(dot)com>
Cc: "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Postgres 11, partitioning with a custom hash function
Date: 2018-10-04 19:39:10
Message-ID: CAKJS1f-aTO=ipnVFuM3N6sf2+Cub+vasxtw4ZN0ei2TTfJ+m4g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 5 October 2018 at 06:18, Harry B <harrysungod(at)gmail(dot)com> wrote:
>
> Thank you David! These helped me create an operator class.
> However, there still seems to be a 'off-by-a-fixed-N' difference between the
> hash value returned and how PG selects the partition.

hmm, actually, this is probably due to the hash_combine64() call in
compute_partition_hash_value(). This seems to combine the hash value
with 0 regardless of if there's another partition key column to hash.
If you could somehow do the reverse of what hash_combine64() will do
to you hash before returning it to the function then you might get
somewhere, but that does not look possible since it appears to be
throwing away some bits.

It may not have been a great choice to decide to have
compute_partition_hash_value() do this unnecessary combine, but it's
likely a few months too late to change that now.

--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Harry B 2018-10-04 20:43:46 Re: Postgres 11, partitioning with a custom hash function
Previous Message Harry B 2018-10-04 17:18:21 Re: Postgres 11, partitioning with a custom hash function