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 1m3XfO-0006Wq-At for pgsql-hackers@arkaria.postgresql.org; Wed, 14 Jul 2021 05:42:42 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1m3XfL-0003jR-W2 for pgsql-hackers@arkaria.postgresql.org; Wed, 14 Jul 2021 05:42:39 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m3XfL-0003j9-OZ for pgsql-hackers@lists.postgresql.org; Wed, 14 Jul 2021 05:42:39 +0000 Received: from mail-wr1-x42c.google.com ([2a00:1450:4864:20::42c]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1m3XfI-0006KV-79 for pgsql-hackers@postgresql.org; Wed, 14 Jul 2021 05:42:39 +0000 Received: by mail-wr1-x42c.google.com with SMTP id l7so1617316wrv.7 for ; Tue, 13 Jul 2021 22:42:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec-at.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:to:cc:date:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=tMWYi6cnbyJwSFZBG5mHECperkupGrLfRA2GE7j8jcI=; b=b1dGo42spCHUPDUWtZiyjKw01YQPrvliuMq1iHuhXGhdwIPEFpAwikj07Fex42jXjm I86niCnwDji4PRDO18QqMEGOD8V1wuG3TAHKxx+KtlgwZf2jf0xgR5LnOREgebsVMwNP 2ScMteXHi9YPKxwAiuSOUve/fNwjoGVEdTAiY7ydJKPJNyl/XOPDFjI83lp+9utEXzH1 6VTqtAQTPn5C8CUKWDacSvsMgIYiMr8xsjEi/r3y9HCL7ikhnKVqpfqFZLCjKpTKhTBZ +l0rU8BmecTldNuBYWb1+82ypfzvirAgIraPV/eBn49mO6nOLk4mL2yeU/ZxmiLhLvIY oneg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=tMWYi6cnbyJwSFZBG5mHECperkupGrLfRA2GE7j8jcI=; b=Hwv+MmBBmXg5mF+9llI66dj8K08TwnbEj1PNbmo2jvdvCqVV0DtEp0QbxkXlWIVKpY GX+dbMckmo5YNM4SIeeEriAvDGy+b4HCPV3g5Uo2l1dV4Yah5DkPRdgBbOdzR82VCKe5 Q7BCMV4XvLZB4RRnZZEEJsIsZTWHLTtBztHgeaXw4UZJ3KNcgyxOMPfE0jHuPctxfY9C 4fcFqqFAvqbdfZcWqFxTrMoWKHdGXmEbi54WGXmLbRLOFsMpS5YvmRi0ac9y+s5RRIjB Pnc1zaYVw6AOrghBYgs5pQIRc/EraI0vTPh8UGdgkLRX01XaR74ylq2P+GxxLODYBwzR hmdA== X-Gm-Message-State: AOAM532zM7AH4d7+TTrjKrautMB8CHyWrzfvcX+eZ6gD9lLGluV+afXX aNj+RrfzgUdC7V6cQqxeGar/4A== X-Google-Smtp-Source: ABdhPJxMl0pFG1zNU4ys6/XvB75PQMCXbkxQs/+WpqP9o8D+7BldrRTXZY1uSnFa1QfsAHADJITkTw== X-Received: by 2002:a5d:4983:: with SMTP id r3mr10314728wrq.383.1626241354934; Tue, 13 Jul 2021 22:42:34 -0700 (PDT) Received: from localhost.localdomain (217-149-168-54.nat.highway.telekom.at. [217.149.168.54]) by smtp.gmail.com with ESMTPSA id e3sm1164335wra.15.2021.07.13.22.42.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 13 Jul 2021 22:42:34 -0700 (PDT) Message-ID: <2c5c19ffe1a812223b2d60b1248ef31e8b51caaa.camel@cybertec.at> Subject: Re: [PATCH] psql: \dn+ to show size of each schema.. From: Laurenz Albe To: Ian Lawrence Barwick , Justin Pryzby Cc: pgsql-hackers Date: Wed, 14 Jul 2021 07:42:33 +0200 In-Reply-To: References: <20210714030725.GG9600@telsasoft.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.5 (3.36.5-2.fc32) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, 2021-07-14 at 14:05 +0900, Ian Lawrence Barwick wrote: > 2021年7月14日(水) 12:07 Justin Pryzby : > > \db+ and \l+ show sizes of tablespaces and databases, so I was surprised in the > > past that \dn+ didn't show sizes of schemas. I would find that somewhat > > convenient, and I assume other people would use it even more useful. > > It's something which would be useful to have. But see this previous proposal: > > https://www.postgresql.org/message-id/flat/2d6d2ebf-4dbc-4f74-17d8-05461f4782e2%40dalibo.com Right, I would not like to cause a lot of I/O activity just to look at the permissions on a schema... Besides, schemas are not physical, but logical containers. So I see a point in measuring the storage used in a certain tablespace, but not so much by all objects in a certain schema. It might be useful for accounting purposes, though. But I don't expect it to be in frequent enough demand to add a psql command. What about inventing a function pg_schema_size(regnamespace)? Yours, Laurenz Albe