store my entire set), but how likely is it to change unannounced in a
minor/security release? Unless of course, you break it in a way that makes
custom-hash function impossible.
Thanks
--
Harry
On Thu, Oct 4, 2018 at 12:39 PM David Rowley
wrote:
> On 5 October 2018 at 06:18, Harry B wrote
values are always off by 1 - whatever I calculate, pg takes
the "next" partition
For a similar setup of 32 partitions, I get the offset (between expected
and selected) as 3 http://dpaste.com/382NDBG
On Wed, Oct 3, 2018 at 8:42 PM David Rowley
wrote:
> On 4 October 2018 at 16:22, Harry B
1
(1 row)
=> select 30::bit(32);
bit
--
0000
(1 row)
I am on intel cpu, x86_64, ubuntu lts 18.4.1
On Wed, Oct 3, 2018 at 9:37 AM Harry B wrote:
>
> Hi,
>
> Since I didn't hear back on how to make partitioning work using a custom
> hash function
lib/pghash/pghash.go
At some point, I will need to revisit this and figure out how to have PG
partition using a custom hash function other than the builtin, or may be pg
will switch to xxhash or siphash.
On Mon, Oct 1, 2018 at 9:41 PM Harry B wrote:
> Hi,
>
> I am interested in trying th
Hi,
I am interested in trying the hash partitioning method now available in 11
(trying the beta 4). However, I have the data already hashed at the
application level across multiple postgres instances. If possible, I would
like to keep these two hashing methods same. This would enable me to move
a
