Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1l25ZZ-0008Cm-Fb for pgsql-admin@arkaria.postgresql.org; Wed, 20 Jan 2021 04:58:25 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1l25ZY-0007Lx-DM for pgsql-admin@arkaria.postgresql.org; Wed, 20 Jan 2021 04:58:24 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1l25ZX-0007Iq-HP for pgsql-admin@lists.postgresql.org; Wed, 20 Jan 2021 04:58:24 +0000 Received: from cloudearth.serversfarm.com ([216.244.65.90]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1l25ZU-00017g-Sh for pgsql-admin@postgresql.org; Wed, 20 Jan 2021 04:58:22 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ibosstech-us.com; s=x; h=Content-Type:Mime-Version:Reply-To:References: In-Reply-To:Message-Id:Date:Cc:Subject:To:From:Sender: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=eRFHvHfVPe7OL7u0t3tvCmGI4vjjcr7twld/7nXSDNw=; b=qv9RgQ2n8EWe6bcLKntZzOV1b BfHmCLDhANtNZbpW4vEHOCYJrRBVa0MKzYthVhyTEyONToRcth+0liDbMpBtJ2u0s/Kd2t7CTfzLS qBFy7jIlrM5+0eTHMujqGxFlbicSTIuqkFZT5tgVCiRVx9XKMcRx0TGPzstWX86HUSTpKHlMtBtex lix8hwrVRr2lxHFdg9UwpiG5i3FaSYWRi3qxM1J6l4eXajvCXwWfqXKEsCBTvt8m1Lqs5e/hTf/oa Yj1yzLSkSem0OYqBixs3rbKq9LB7yimf6aEnaIScF3IpUb+QYy+awdlQoTRqPKfvI0n6DZQdT3NMC CcU0lyA0Q==; Received: from [171.61.169.118] (helo=[192.168.1.11]) by cloudearth.serversfarm.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1l25ZQ-00688p-RK; Tue, 19 Jan 2021 23:58:17 -0500 From: "Anjul Tyagi" To: "Amit jain" , "Keith Fiske" Subject: Re: Table Partitioning Cc: depesz@depesz.com, pgsql-admin Date: Wed, 20 Jan 2021 04:58:11 +0000 Message-Id: In-Reply-To: References: <20210119114246.GA13372@depesz.com> <20210119121204.GB13372@depesz.com> Reply-To: "Anjul Tyagi" User-Agent: eM_Client/8.1.979.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MBA4A79806-9DFE-4450-AA35-6BE4695B4C31" X-Authenticated-Id: anjul@ibosstech-us.com List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --------=_MBA4A79806-9DFE-4450-AA35-6BE4695B4C31 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Thanks Amit and Keith for your advise. Regards, Anjul TYAGI =C3=BC Go Green ------ Original Message ------ From: "Amit jain" To: "Keith Fiske" Cc: depesz@depesz.com; "Anjul Tyagi" ;=20 "pgsql-admin" 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=20 >than managing partitioning code. > >Even PG version 11 has lot of partitioning features over older one, was=20 >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=20 > wrote: >> >> >>On Tue, Jan 19, 2021 at 7:12 AM hubert depesz lubaczewski=20 >> 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=20 >>able to find a good trigger-based, solution to these kinds of updates=20 >>for pg_partman myself. Thankfully support for updates that move data=20 >>between child tables was added for native partitioning in PG11. I=20 >>would highly suggest planning an upgrade to your major version of PG.=20 >>Skip 11 and go right to 12 or 13. An upgrade would be arguably easier=20 >>than trying to code this yourself. And the added features to native=20 >>partitioning in 11 and above will make managing them far better in the=20 >>long run. >> >>-- >>Keith Fiske >>Senior Database Engineer >>Crunchy Data - http://crunchydata.com --------=_MBA4A79806-9DFE-4450-AA35-6BE4695B4C31 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Thanks Amit and Keith = for your advise.

=C2=A0
=C2=A0
=C2=A0

Regards,

Anjul TYAGI

=C2=A0

=C3=BC<= /b>=C2=A0Go=C2= =A0Green


------ Original Message ------
From: "Amit jain" <amit7.ja= in@gmail.com>
To: "Keith Fiske" <k= eith.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 Upgr= ade rather than managing partitioning code.=C2=A0

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:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">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 po= ssible, but very tricky. I was never able to find a good trigger-based, sol= ution to these kinds of updates for pg_partman myself. Thankfully support f= or updates that move data between child tables was added for native partiti= oning in PG11. I would highly suggest planning an upgrade to your major ver= sion 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
Crun= chy Data - http://crunchydata.com
--------=_MBA4A79806-9DFE-4450-AA35-6BE4695B4C31--