Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gs9hM-0000ic-Up for pgsql-admin@arkaria.postgresql.org; Fri, 08 Feb 2019 17:12:21 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gs9hL-0003aN-GU for pgsql-admin@arkaria.postgresql.org; Fri, 08 Feb 2019 17:12:19 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gs9hL-0003aG-7d for pgsql-admin@lists.postgresql.org; Fri, 08 Feb 2019 17:12:19 +0000 Received: from mout.perfora.net ([74.208.4.196]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gs9hI-0005N8-O5 for pgsql-admin@lists.postgresql.org; Fri, 08 Feb 2019 17:12:18 +0000 Received: from [192.168.1.101] ([98.169.208.73]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MLQEG-1gshvR0ftC-000evF; Fri, 08 Feb 2019 18:12:07 +0100 Message-ID: <5C5DB866.30206@sqlexec.com> Date: Fri, 08 Feb 2019 12:12:06 -0500 From: MichaelDBA User-Agent: Postbox 5.0.25 (Windows/20180328) MIME-Version: 1.0 To: Vijaykumar Jain CC: Jeremiah Bauer , "pgsql-admin@lists.postgresql.org" Subject: Re: [External] Postgres Database Disk Usage References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030208080904020001070302" X-Provags-ID: V03:K1:71Y6EJPseXILrzVNqYiGkcwtgDN1KCetc1tZV44GcNLa/on/OM0 4DADjKwYti2GsEfJiWUZOk/yjJsi8jKocmdxxwKR6CMLkd1uwq5jZrRrmUEmsqYNbdxXRQ0 9nf/1c7pECpHC/Y7NQ6PMagDj2n+Nb8Mba+xmBz2wXUlY965MAxXmAVYbsGLGbbvFmPwiH0 WJ6JxYm8HCgBwkRPIB/0Q== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:6Hrm4UutxJY=:xRy/7uyypbR36/yRmit01M bermUG5ywsu6nSx48DLkHvXPEUlNFNNGrbDkNQYpwnCfRU7HC/HDpLSTyldZ85Lt+0dz/ourO Qd91rzZs6SLpf0ICORQrfCxVvSey54+dl3EsffPBhlqtnS/LeSSuVANknO2yqv25LA0MZt0YR eguH2j6mkY7lXk3yLytjvnZRfTgz5vW2jvlpeanQF44FM0kJZKI7B3Hl+aGXLH4S3LvMRs6c9 gBgnIv/fo+ujiBZzPqqgKzR7OL+ec05vl3hYpkgAVsQ6iaBx8BiGEPSqGg5ZjQkgR7kznFkFF eH+zZi4ZKreP9FCCuvWgvOhRCeT/5iHxrUUq7CDcU2k9pztB5J6RIHzY+gItgb3No1sSrIHyD A0vK3hL+RMgMvhZpP98CtFTJAZoxnRILSXlSlvsIgcGqUnRo0xko7iSECU3w1V5KRswXSzWPW fmLK0AFiVZsCEIsrPu1e4P4iwxQvL4kM3KBQpykqIgCHM47dFeNww5+f7/iXYHZb5KcsYHJmW oa8yK1hbnv0bld2CPxbTWi+fxmE8quZ5neYuqhWO7WMP32Duj89LLBJk2/OSCWXAlqgF48FHG jel1JEvurgEeL3x1dy7x1KItjegN87oHCEP4IFCo9LFMjsplyvstviYkPAq97NI7iQ9ONnkGp HkodclSXeAjDFnmyZ67+8SWyHmP6RJsNM0H6CyPsPQPEAAU+ddaWVqTxHoOE/sXRLoGALo6pO c/LundhvHcnhTaI/aPA09gW6Zj1h3ash/Ax8ffx+Er5s27sACmYI2J5pfqA= List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk This is a multi-part message in MIME format. --------------030208080904020001070302 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Would you use pg_total_relation_size, not pg_relation_size in your sizing query? This will capture associated indexes and such. Regards, Michael Vitale > Vijaykumar Jain > Friday, February 8, 2019 12:05 PM > Ok I am out of ideas :) > Sorry, I’ll let the experts step in here :) > > btw the 43GB and 439MB look close :) I hope there is no conversion > error :) > > -- > > Regards, > Vijay > Jeremiah Bauer > Friday, February 8, 2019 11:29 AM > We don't have any blobs or json objects in this database. I've > sanitized the output of the query below, and toast doesn't show up > until well down the list. > > FVDM=# SELECT nspname || '.' || relname AS "relation", > FVDM-# pg_size_pretty(pg_relation_size(C.oid)) AS "size" > FVDM-# FROM pg_class C > FVDM-# LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace) > FVDM-# WHERE nspname NOT IN ('pg_catalog', 'information_schema') > FVDM-# ORDER BY pg_relation_size(C.oid) DESC > FVDM-# LIMIT 20; > relation | size > ------------------------------------------------------+--------- > mart.*****_data | 301 MB > mart.detailed_***** | 66 MB > mart.major_***** | 58 MB > public.temp_***** | 20 MB > public.temp_***** | 13 MB > mart.customer_***** | 11 MB > public.temp_*****| 11 MB > mart.major_***** | 1888 kB > public.temp_***** | 1880 kB > public.hold_***** | 1424 kB > public.temp_***** | 1208 kB > mart.ranking_***** | 1144 kB > public.temp_***** | 1080 kB > public.temp_***** | 984 kB > mart.customer_***** | 696 kB > mart.economic_***** | 456 kB > public.hold_***** | 448 kB > mart.expanded_***** | 384 kB > pg_toast.pg_toast_2618 | 376 kB > public.temp_***** | 232 kB > > I also queried just for toast tables: > > FVDM=# SELECT nspname || '.' || relname AS "relation", > pg_size_pretty(pg_relation_size(C.oid)) AS "size" > FROM pg_class C > LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace) > WHERE nspname NOT IN ('pg_catalog', 'information_schema') and > c.relname ~* 'toast' > ORDER BY pg_relation_size(C.oid) DESC > LIMIT 20; > relation | size > -------------------------------+------------ > pg_toast.pg_toast_2618 | 376 kB > pg_toast.pg_toast_2619 | 48 kB > pg_toast.pg_toast_2618_index | 16 kB > pg_toast.pg_toast_2619_index | 16 kB > pg_toast.pg_toast_13104_index | 8192 bytes > pg_toast.pg_toast_3596_index | 8192 bytes > pg_toast.pg_toast_2606_index | 8192 bytes > pg_toast.pg_toast_2620_index | 8192 bytes > pg_toast.pg_toast_2609_index | 8192 bytes > pg_toast.pg_toast_2396_index | 8192 bytes > pg_toast.pg_toast_3592_index | 8192 bytes > pg_toast.pg_toast_1255_index | 8192 bytes > pg_toast.pg_toast_13109_index | 8192 bytes > pg_toast.pg_toast_13114_index | 8192 bytes > pg_toast.pg_toast_13119_index | 8192 bytes > pg_toast.pg_toast_13124_index | 8192 bytes > pg_toast.pg_toast_13129_index | 8192 bytes > pg_toast.pg_toast_13134_index | 8192 bytes > pg_toast.pg_toast_2604_index | 8192 bytes > pg_toast.pg_toast_2964_index | 8192 bytes > > -- > > > Jeremiah > > ------------------------------------------------------------------------ > *From:* Vijaykumar Jain > *Sent:* Friday, February 8, 2019 11:21 AM > *To:* Jeremiah Bauer > *Cc:* pgsql-admin@lists.postgresql.org > *Subject:* Re: [External] Postgres Database Disk Usage > Do you have any blobs or large json objects as relnames? > they generally end up as toast tables . > Which may be the ones holding the space. > > > > On Fri, 8 Feb 2019 at 9:25 PM Jeremiah Bauer > wrote: > -- > > Regards, > Vijay > CONFIDENTIALITY NOTICE: The information contained in this email (and > any attachments) is privileged and confidential and protected from > disclosure. If you are not the intended recipient of this email or the > attachments, be aware that any disclosure, copying, distribution or > use of this email or any attachment is strictly prohibited and you > should not read the message or read or open any attachment. If you > have received this email by mistake, please immediately notify the > sender and delete it permanently from your system. Agri Stats, Inc. > and its subsidiaries will not be held liable to any person or entity > resulting from the unintended or unauthorized use of any information > contained in this email. --------------030208080904020001070302 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Would you use pg_total_relation_size, not pg_relation_size in your sizing query?  This will capture associated indexes and such.

Regards,
Michael Vitale

Friday, February 8, 2019 12:05 PM
Ok I am out of ideas :)
Sorry, I’ll let the experts step in here :)

 btw the 43GB and 439MB look close :) I hope there is no conversion error :) 

--

Regards,
Vijay
Friday, February 8, 2019 11:29 AM
We don't have any blobs or json objects in this database.  I've sanitized the output of the query below, and toast doesn't show up until well down the list.

FVDM=# SELECT nspname || '.' || relname AS "relation",
FVDM-#     pg_size_pretty(pg_relation_size(C.oid)) AS "size"
FVDM-#   FROM pg_class C
FVDM-#   LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace)
FVDM-#   WHERE nspname NOT IN ('pg_catalog', 'information_schema')
FVDM-#   ORDER BY pg_relation_size(C.oid) DESC
FVDM-#   LIMIT 20;
                       relation                       |  size  
------------------------------------------------------+---------
 mart.*****_data                                        | 301 MB
 mart.detailed_*****                 | 66 MB
 mart.major_*****              | 58 MB
 public.temp_*****                                 | 20 MB
 public.temp_*****                      | 13 MB
 mart.customer_*****       | 11 MB
 public.temp_*****| 11 MB
 mart.major_*****                  | 1888 kB
 public.temp_*****            | 1880 kB
 public.hold_*****           | 1424 kB
 public.temp_*****                          | 1208 kB
 mart.ranking_*****                                 | 1144 kB
 public.temp_*****          | 1080 kB
 public.temp_*****       | 984 kB
 mart.customer_*****                      | 696 kB
 mart.economic_*****                      | 456 kB
 public.hold_*****                          | 448 kB
 mart.expanded_*****             | 384 kB
 pg_toast.pg_toast_2618                               | 376 kB
 public.temp_*****       | 232 kB

I also queried just for toast tables:

FVDM=# SELECT nspname || '.' || relname AS "relation",
    pg_size_pretty(pg_relation_size(C.oid)) AS "size"
  FROM pg_class C
  LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace)
  WHERE nspname NOT IN ('pg_catalog', 'information_schema') and c.relname ~* 'toast'
  ORDER BY pg_relation_size(C.oid) DESC
  LIMIT 20;
           relation            |    size    
-------------------------------+------------
 pg_toast.pg_toast_2618        | 376 kB
 pg_toast.pg_toast_2619        | 48 kB
 pg_toast.pg_toast_2618_index  | 16 kB
 pg_toast.pg_toast_2619_index  | 16 kB
 pg_toast.pg_toast_13104_index | 8192 bytes
 pg_toast.pg_toast_3596_index  | 8192 bytes
 pg_toast.pg_toast_2606_index  | 8192 bytes
 pg_toast.pg_toast_2620_index  | 8192 bytes
 pg_toast.pg_toast_2609_index  | 8192 bytes
 pg_toast.pg_toast_2396_index  | 8192 bytes
 pg_toast.pg_toast_3592_index  | 8192 bytes
 pg_toast.pg_toast_1255_index  | 8192 bytes
 pg_toast.pg_toast_13109_index | 8192 bytes
 pg_toast.pg_toast_13114_index | 8192 bytes
 pg_toast.pg_toast_13119_index | 8192 bytes
 pg_toast.pg_toast_13124_index | 8192 bytes
 pg_toast.pg_toast_13129_index | 8192 bytes
 pg_toast.pg_toast_13134_index | 8192 bytes
 pg_toast.pg_toast_2604_index  | 8192 bytes
 pg_toast.pg_toast_2964_index  | 8192 bytes

--


Jeremiah

From: Vijaykumar Jain <vjain@opentable.com>
Sent: Friday, February 8, 2019 11:21 AM
To: Jeremiah Bauer
Cc: pgsql-admin@lists.postgresql.org
Subject: Re: [External] Postgres Database Disk Usage
 
Do you have any blobs or large json objects as relnames?
they generally end up as toast tables .
Which may be the ones holding the space.



On Fri, 8 Feb 2019 at 9:25 PM Jeremiah Bauer <jbauer@agristats.com> wrote:
--

Regards,
Vijay
CONFIDENTIALITY NOTICE: The information contained in this email (and any attachments) is privileged and confidential and protected from disclosure. If you are not the intended recipient of this email or the attachments, be aware that any disclosure, copying, distribution or use of this email or any attachment is strictly prohibited and you should not read the message or read or open any attachment. If you have received this email by mistake, please immediately notify the sender and delete it permanently from your system. Agri Stats, Inc. and its subsidiaries will not be held liable to any person or entity resulting from the unintended or unauthorized use of any information contained in this email.

--------------030208080904020001070302--