From: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
---|---|
To: | Christoph Berg <myon(at)debian(dot)org> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Monitoring disk space from within the server |
Date: | 2019-11-08 13:32:13 |
Message-ID: | CAOBaU_YVGEnsnP1ufp42NiJ+WvPHRWBOsBOcaxWxsbXPN_sdNQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Nov 8, 2019 at 2:24 PM Christoph Berg <myon(at)debian(dot)org> wrote:
>
> Monitoring the available disk space is the topmost thing on the
> priority for PostgreSQL operation, yet this metric is not available
> from the SQL level.
>
> The attached patch implements a function pg_tablespace_statfs(tblspc)
> to report disk space numbers per tablespace:
>
> # select * from pg_tablespace_statfs('pg_default');
> blocks │ bfree │ bavail │ files │ ffree
> ───────────┼──────────┼──────────┼──────────┼──────────
> 103179564 │ 20829222 │ 20815126 │ 26214400 │ 24426295
>
> Open points:
> * should these numbers be converted to bytes?
> * the column names currently mirror the statfs() names and should
> certainly be improved
> * which of these columns add to \db+ output?
> * possibly extend this (and \db) to pg_wal
Shouldn't we have something more generic, in hope that this eventually
get implemented on Windows? I'm also wondering if getting the fs
information is enough, as there might be quota.
From | Date | Subject | |
---|---|---|---|
Next Message | Christoph Berg | 2019-11-08 13:35:31 | Re: Monitoring disk space from within the server |
Previous Message | Konstantin Knizhnik | 2019-11-08 13:31:07 | Re: Why overhead of SPI is so large? |