Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1szOuf-005qgP-Tb for pgsql-general@arkaria.postgresql.org; Fri, 11 Oct 2024 23:19:13 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1szOud-00Dcg8-J0 for pgsql-general@arkaria.postgresql.org; Fri, 11 Oct 2024 23:19:11 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1szOud-00Dcg0-6T for pgsql-general@lists.postgresql.org; Fri, 11 Oct 2024 23:19:11 +0000 Received: from mout-u-107.mailbox.org ([2001:67c:2050:101:465::107]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1szOuZ-000aRA-22 for pgsql-general@postgresql.org; Fri, 11 Oct 2024 23:19:10 +0000 Received: from smtp2.mailbox.org (smtp2.mailbox.org [10.196.197.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-u-107.mailbox.org (Postfix) with ESMTPS id 4XQMyJ4Nypz9t9S; Sat, 12 Oct 2024 01:19:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ewie.name; s=MBO0001; t=1728688744; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=GW9tXQdLa7SiYjB/EfIs48UIrv8UazV14wp6YBELsSI=; b=b2cuul/gVdcResDbzPSvq3qAj6Z1vm0nbZIV7DFb5woSNl9RtptO7JIHWbSb7ZEUMjCjht HJkVOJe/iLPGmsT4ROWqNiThXFnndIf1AopZB9DkwPg30EUg6UQU2vc/QN0rQEE71zX1sg J/cwxpt9WEgmaz02AYiE6EU+g+Bp3J+oGOltF9C+hwuARcHiN4WqAoGTyMqLJ5EfYTVqGZ wQpX4IWVAIL9y9mdQgVbq+IuqAm+I0+yJNBK2xYvYTmujbOBWoIb1pan19OR3Ea1720tBH zfl+cpl+Xx5+o0ilZt8hcoCVHm12LxISgCg6WZHYjb+7HFb63RkgVYL21lXCXA== Date: Sat, 12 Oct 2024 01:19:02 +0200 From: Erik Wienhold To: Kaushal Shriyan Cc: Postgres General Subject: Re: Prune or Purge data stored on Postgres 14.13 Message-ID: <6847b65a-1344-45b8-b9bb-56fe9d0d0365@ewie.name> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2024-10-11 20:43 +0200, Kaushal Shriyan wrote: > I am running PostgreSQL 14.13 on RHEL 8.10 OS. Is there a way to Prune or > Purge data stored on PostgreSQL 14.13 ? > > For example I have Analytics data stored in PostgreSQL 14.13 server for > last 1 year (1st September 2023 till date) > > Is there a way to prune analytics data from Analytics Data stored on > PostgreSQL 14.13 Database server starting from 1st September 2023 till > February 29, 2024 and archive it to a tape drive or network file storage? > (Six months analytics data). This is to make sure we do not run into an out > of disk/storage space situation. Once we carry out the prune operation, we > only have 6 months of data in the PG Database server and the older data > beyond six months will be on tape drive or network file storage. Use tablespaces[1] to store data on external storage. Is the table already partitioned? If yes, than you can use ALTER TABLE to move the partitions that end before 2024-03-01 to a tablespace on external storage. If the table is not partitioned[2] then you should think about doing that because it simplifies the pruning/archiving process if it's going to be a regular task. But existing tables cannot be partitioned. You'd have to create a new table and attach partitions. But the existing table can also be attached as one partition and you can wait 6 more months when you probably want to purge data again. Let's say you create those partitions now (October 2024), then the current data will go into a partition P until 2024-11-01 and newer data will go into the next partition. After 2025-05-01 you can move partition P to another tablespace. This of course depends on how much disk space you can still afford in that time. But this could also work without partitioning if the archived data is not required to be available alongside the live data. Every 6 months you could create a new archive table with a tablespace on external storage and insert the rows of the last 6 months into that new archive table. Then delete those rows from the live table and VACUUM it. The live table will still use the same amount of disk space (unless you use VACUUM FULL which will, however, use extra disk space while writing a new copy of the table), but new rows will occupy the disk space that was previously occupied by the now-deleted rows and reclaimed by VACUUM. Hope that helps. [1] https://www.postgresql.org/docs/14/manage-ag-tablespaces.html [2] https://www.postgresql.org/docs/14/ddl-partitioning.html -- Erik