Re: Related To Hash Partition

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
>

In response to

Browse pgsql-admin by date

  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