Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dnQpK-0002Um-3u for pgsql-admin@arkaria.postgresql.org; Thu, 31 Aug 2017 14:52:14 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1dnQpJ-0000be-GC for pgsql-admin@arkaria.postgresql.org; Thu, 31 Aug 2017 14:52:13 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dnQpI-0000ar-Ou for pgsql-admin@postgresql.org; Thu, 31 Aug 2017 14:52:12 +0000 Received: from mail-wm0-x22f.google.com ([2a00:1450:400c:c09::22f]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1dnQpF-0000gG-Da for pgsql-admin@postgresql.org; Thu, 31 Aug 2017 14:52:11 +0000 Received: by mail-wm0-x22f.google.com with SMTP id 187so6038487wmn.1 for ; Thu, 31 Aug 2017 07:52:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=greycortex-com.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version; bh=fnW6kE9NdxK80Zt5cf/9hPpx2jPCJfM+UMeFj8YoE2o=; b=BQPNIFSiBX02t6L/+iXRDI8yDj91mykJ86iwNcBXC5c0Q2vmbbVF+1NKEp+QszIkdY M/pdL8Qf3/iZzTyn7ZMs74XatIyX58u/GOAIDDbpJRJpM0l4J4+gx3syo1JNO1WejzuH MPKjeiadb1nTB8T0unxSaLxlRoLoL4vxQ1cNI56iT1vmGWgn1G3EazUA+zr2Z1bH9Xx0 FUh+FUb9r7wmBdQDY41qkS4lSjnh1wNpjE0a/qtPcB6J744QerezXOi6mpeIvsRoHMpP k/Hc7gvbeoIZxOc/T9/6aooGwmAG2uHN/IkLpNCvLjzK5oNqbsUbokSUSBZvyvvvSJQs JPCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=fnW6kE9NdxK80Zt5cf/9hPpx2jPCJfM+UMeFj8YoE2o=; b=B9eRKQsIDPoeEUcbFOBlilkEVbLJ67vkl0X9UhsFhUEqDPDdnUodHU7QzlLek6MQH4 hPj2ZW0hB7PXz4wXN9pxLUWCDzpMcgJGnX7rkaV6ldiIsE8o3u6IpHiAEt78EsvvfJtb QzVpB5WIzNbeAu/tJTaVgeQgrxqplOTHWm5TnpBKFBGA0twYSC7AMOto7kfIQkO0w/dR XEVd8W/3zWaDIFv01xL8552rVQAXsLD9eJUzpMDdKnvoy25RbOFL9YK8owu/fkxCdj31 4QRoRIC6t/CgcjAPUVZtuExq2AxgVi5fJiEDrR82DshgZ82+X0zkA7CO1+4oFVRulyJg gVxA== X-Gm-Message-State: AHYfb5gXI4z9OnJPV93CiW3T6Q/leOyspaWOynN12CSl8G+BGaPpy+ub 7+txj08QOjcvO2jxgEkz6g== X-Google-Smtp-Source: ADKCNb7FxjmolsDTeL/KW13hqzy1ome/T48jmHN85C/9ZQGhsrKvVCSTxUNeQeqSV8StBJ5+OGXp7Q== X-Received: by 10.28.69.155 with SMTP id l27mr686990wmi.122.1504191127314; Thu, 31 Aug 2017 07:52:07 -0700 (PDT) Received: from mmerta.greycortex.com ([195.113.243.75]) by smtp.gmail.com with ESMTPSA id 74sm320197wmk.9.2017.08.31.07.52.05 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 31 Aug 2017 07:52:06 -0700 (PDT) To: pgsql-admin From: Michal Merta Subject: Amount of unused space on a storage device Message-ID: <37bd3391-30db-292c-0cf9-110860461b0d@greycortex.com> Date: Thu, 31 Aug 2017 16:52:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------B6B9B3167B1CF3182BDB3F1A" List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-admin Precedence: bulk Sender: pgsql-admin-owner@postgresql.org This is a multi-part message in MIME format. --------------B6B9B3167B1CF3182BDB3F1A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hello everyone, We have an OLAP database on dedicated RAID storage with a total capacity of 100TB. The transaction log and temp_tablespace are stored on a separated drive. All tables are partitioned by timestamp of insert, the size of each partition is 1 week. All tables are insert only, no update or delete ever occurs. The amount of data stored peer week is ~1TB. We use following maintenance algorithm: IF amount of free space on storage is lower than BOUNDARY, THEN backup all partitions for oldest week drop these partitions from database Our desired behavior is to keep as much data as possible in database for analytical queries. My question is: Having 100TB capacity and data coming in at a fixed rate of ~1TB per week, what would be an optimal BOUNDARY? Or to put it another way, what is a reasonable amount of unused space on a storage device of this size? Thanks & Regards, Michal Merta --------------B6B9B3167B1CF3182BDB3F1A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hello everyone,

We have an OLAP database on dedicated RAID storage with a total capacity of 100TB. The transaction log and temp_tablespace are stored on a separated drive.
All tables are partitioned by timestamp of insert, the size of each partition is 1 week. All tables are insert only, no update or delete ever occurs. The amount of data stored peer week is ~1TB.

We use following maintenance algorithm:
  IF amount of free space on storage is lower than BOUNDARY, THEN
    backup all partitions for oldest week
    drop these partitions from database

Our desired behavior is to keep as much data as possible in database for analytical queries.

My question is:
Having 100TB capacity and data coming in at a fixed rate of ~1TB per week, what would be an optimal BOUNDARY? Or to put it another way, what is a reasonable amount of unused space on a storage device of this size?

Thanks & Regards,
Michal Merta
--------------B6B9B3167B1CF3182BDB3F1A--