Re: Related To Hash Partition - Mailing list pgsql-admin

From ROHIT SACHDEVA
Subject Re: Related To Hash Partition
Date
Msg-id CAKDb7aF0CYNkX+abv+Q=CuFS3ZmbW0cJPdDmmZQ2GkOZ0WeJ+g@mail.gmail.com
Whole thread Raw
In response to Re: Related To Hash Partition  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-admin

Hi Tom,

 Thanks for your reply.
 
What will be the best approach to getting rid of this problem now?
 
1. Remove the hash partition and go for range or list, which, frankly speaking, is not feasible in my case.
2. Truncate the table and insert the data again, but that will not guarantee that this problem will not arise again in future.
3. To disable the enable_partition_prunning flag, but I think the cost will increase for fetching the records if i disable it, or will things be okay ?
 
 
Any other thing that I can do to get rid of it? What do you suggest?


On Sun, 23 Apr, 2023, 8:37 pm Tom Lane, <tgl@sss.pgh.pa.us> wrote:
ROHIT SACHDEVA <sachdeva.rohit648@gmail.com> writes:
> While using hash partition i am facing the problem that the data is not
> going into the proper partition table .

Define "proper".  It's generally best to assume that the hash function
is a black box --- if you assume you know which partition a given key
value will be mapped to, you are doing something very fragile, and people
will have no sympathy for you when it breaks.

If you want a predictable mapping, use list or range partitioning,
not hash.

                        regards, tom lane

pgsql-admin by date:

Previous
From: Tom Lane
Date:
Subject: Re: Related To Hash Partition
Next
From: fatih abztn
Date:
Subject: pgBouncer - got packet 'D' from server when not linked WARNING messages