| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
| Cc: | Christoph Moench-Tegeder <cmt(at)burggraben(dot)net>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, Christoph Berg <myon(at)debian(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Monitoring disk space from within the server |
| Date: | 2019-11-12 09:03:00 |
| Message-ID: | 20191112090300.GP1549@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Nov 12, 2019 at 09:47:47AM +0100, Daniel Gustafsson wrote:
> I agree with Tomas upthread that it's unclear whether this needs to be in core.
> There are many system parameters a database admin is likely to be interested
> in, diskspace being just one of them (albeit a very important one for many
> reasons), and there is nothing that makes the SQL interface (or postgres core
> for that matter) particularly more suited for this job than other existing
> tools.
>
> Why is SQL level crucial for this?
Because this makes the monitoring experience easier from a remote
perspective. FWIW, I have cases it would have been useful to monitor
out the physical amount of space available with the amount of space
covered by bloated tables for a given set of tablespaces through a
single source.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2019-11-12 09:03:30 | Re: pg_waldump and PREPARE |
| Previous Message | Amit Kapila | 2019-11-12 08:55:19 | Re: [HACKERS] Block level parallel vacuum |