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@xxxxxxxxxxxxx> wrote:
ROHIT SACHDEVA <sachdeva.rohit648@xxxxxxxxx> 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
