Re: Table Partitioning - Mailing list pgsql-admin

From Anjul Tyagi
Subject Re: Table Partitioning
Date
Msg-id em49306724-d3b0-40e7-ac2f-fd07dcb60e9b@iboss01108
Whole thread Raw
In response to Re: Table Partitioning  (Amit jain <amit7.jain@gmail.com>)
List pgsql-admin
Thanks Amit and Keith for your advise.

 
 
 

Regards,

Anjul TYAGI

 

ü Go Green


------ Original Message ------
From: "Amit jain" <amit7.jain@gmail.com>
To: "Keith Fiske" <keith.fiske@crunchydata.com>
Sent: 1/19/2021 8:45:31 PM
Subject: Re: Table Partitioning

I am totally agree with Keith opinion on better to go Upgrade rather than managing partitioning code. 

Even PG version 11 has lot of partitioning features over older one, was written a blog on same, can have a glance.


On Tue, Jan 19, 2021 at 7:03 PM Keith Fiske <keith.fiske@crunchydata.com> wrote:


On Tue, Jan 19, 2021 at 7:12 AM hubert depesz lubaczewski <depesz@depesz.com> wrote:
On Tue, Jan 19, 2021 at 12:01:12PM +0000, Anjul Tyagi wrote:
> Can we handle that in DB side with trigger?

I don't think so. At least not easily.

You could make a function to do so, though.

Best regards,

depesz




As depesz said, a trigger is possible, but very tricky. I was never able to find a good trigger-based, solution to these kinds of updates for pg_partman myself. Thankfully support for updates that move data between child tables was added for native partitioning in PG11. I would highly suggest planning an upgrade to your major version of PG. Skip 11 and go right to 12 or 13. An upgrade would be arguably easier than trying to code this yourself. And the added features to native partitioning in 11 and above will make managing them far better in the long run.

--
Keith Fiske
Senior Database Engineer
Crunchy Data - http://crunchydata.com

pgsql-admin by date:

Previous
From: Adrian Ho
Date:
Subject: Re: TIL: In pg_dump, beware the combo of "-Fd" and "-Z"
Next
From: Ron
Date:
Subject: Re: TIL: In pg_dump, beware the combo of "-Fd" and "-Z"