Re: identify partitioning columns and best practices of partitioning in prod enviornments - Mailing list pgsql-general

From Michael Lewis
Subject Re: identify partitioning columns and best practices of partitioning in prod enviornments
Date
Msg-id CAHOFxGrvRKKz25Vdcj9E0Bvb9g8kY-3_t4Xkz6pGu9R_DwSFvA@mail.gmail.com
Whole thread Raw
In response to Re: identify partitioning columns and best practices of partitioning in prod enviornments  (Ron <ronljohnsonjr@gmail.com>)
List pgsql-general
On Wed, Nov 11, 2020 at 3:58 PM Ron <ronljohnsonjr@gmail.com> wrote:
On 11/11/20 4:31 PM, Atul Kumar wrote:
> Hi,
>
> I want to about best practices of partitioning in prod environments
> and how to identify partitioning columns.

It depends on what you want to do.  If your purpose is to simplify the
deletion of old records, then partition by an unchanging date field.
If your purpose is to increase locality of data (because many of your
queries are an equality on a specific "group id"), then partition by that
"group id" field.

Additionally, while partitioning is hugely improved in v12 (and perhaps 13, I forget), there are still restrictions on what you can partition on & what you can have a primary key on. Also of note that having more than hundreds or low thousands of partitions may have a significant impact on planning and execution times. It is a great tool, but sometimes is implemented badly or prematurely and the cost may not be worth a theoretical benefit.

Are you just wanting to learn about partitioning, or do you have a specific situation that you think would benefit from partitioning?

pgsql-general by date:

Previous
From: Ron
Date:
Subject: Re: identify partitioning columns and best practices of partitioning in prod enviornments
Next
From: Tatsuo Ishii
Date:
Subject: Re: Need to place pgpool logs on separate directory