From: | ROHIT SACHDEVA <sachdeva(dot)rohit648(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-admin(at)lists(dot)postgresql(dot)org |
Subject: | Re: Related To Hash Partition |
Date: | 2023-04-23 17:34:53 |
Message-ID: | CAKDb7aF0CYNkX+abv+Q=CuFS3ZmbW0cJPdDmmZQ2GkOZ0WeJ+g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> ROHIT SACHDEVA <sachdeva(dot)rohit648(at)gmail(dot)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
>
From | Date | Subject | |
---|---|---|---|
Next Message | fatih abztn | 2023-04-26 13:28:40 | pgBouncer - got packet 'D' from server when not linked WARNING messages |
Previous Message | Tom Lane | 2023-04-23 15:07:34 | Re: Related To Hash Partition |