Re: Table Partitioning

Thanks Amit and Keith for your advise.

Regards,

Anjul TYAGI

ü Go Green

------ Original Message ------
From: "Amit jain" <amit7(dot)jain(at)gmail(dot)com>
To: "Keith Fiske" <keith(dot)fiske(at)crunchydata(dot)com>
Cc: depesz(at)depesz(dot)com; "Anjul Tyagi" <anjul(at)ibosstech-us(dot)com>;
"pgsql-admin" <pgsql-admin(at)postgresql(dot)org>
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.
>https://severalnines.com/database-blog/how-take-advantage-new-partitioning-features-postgresql-11
>
>
>On Tue, Jan 19, 2021 at 7:03 PM Keith Fiske
><keith(dot)fiske(at)crunchydata(dot)com> wrote:
>>
>>
>>On Tue, Jan 19, 2021 at 7:12 AM hubert depesz lubaczewski
>><depesz(at)depesz(dot)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