Re: Related To Hash Partition

Поиск
Список
Период
Сортировка
От ROHIT SACHDEVA
Тема Re: Related To Hash Partition
Дата
Msg-id CAKDb7aF0CYNkX+abv+Q=CuFS3ZmbW0cJPdDmmZQ2GkOZ0WeJ+g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Related To Hash Partition  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Related To Hash Partition
Следующее
От: fatih abztn
Дата:
Сообщение: pgBouncer - got packet 'D' from server when not linked WARNING messages