Re: Partitioning options
| От | Greg Sabino Mullane |
|---|---|
| Тема | Re: Partitioning options |
| Дата | |
| Msg-id | CAKAnmmLS6S0HvQdDh94u5hNXBVOFg8pqB3pY+1Z4SGg+MAFq1A@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Partitioning options (veem v <veema0000@gmail.com>) |
| Ответы |
Re: Partitioning options
|
| Список | pgsql-general |
Out of curiosity, As OP mentioned that there will be Joins and also filters on column Customer_id column , so why don't you think that subpartition by customer_id will be a good option? I understand List subpartition may not be an option considering the new customer_ids gets added slowly in the future(and default list may not be allowed) and also OP mentioned, there is skewed distribution of data for customer_id column. However what is the problem if OP will opt for HASH subpartition on customer_id in this situation?
It doesn't really gain you much, given you would be hashing it, the customers are unevenly distributed, and OP talked about filtering on the customer_id column. A hash partition would just be a lot more work and complexity for us humans and for Postgres. Partitioning for the sake of partitioning is not a good thing. Yes, smaller tables are better, but they have to be smaller targeted tables.
sud wrote:
130GB of storage space as we verified using the "pg_relation_size" function, for a sample data set.
You might also want to closely examine your schema. At that scale, every byte saved per row can add up.
Cheers,
Greg
В списке pgsql-general по дате отправления: