| From: | Christoph Berg <myon(at)debian(dot)org> |
|---|---|
| To: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Christoph Moench-Tegeder <cmt(at)burggraben(dot)net>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Monitoring disk space from within the server |
| Date: | 2019-11-12 09:04:24 |
| Message-ID: | 20191112090424.GA20731@msg.df7cb.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Re: Daniel Gustafsson 2019-11-12 <7A3B9BB6-BEA0-466E-98A9-B4DD8F04830E(at)yesql(dot)se>
> 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 the figure is interesting to users as well. They will usually
not have any access to monitoring, and checking if they can load this
extra 10 GB dataset is a good use case.
This is about providing the numbers in the place where they are
needed. Of course admins can just go elsewhere to look it up (and
probably will), but I think now there's a usability gap for people who
just have SQL access.
Christoph
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Julien Rouhaud | 2019-11-12 09:07:28 | Re: Monitoring disk space from within the server |
| Previous Message | Michael Paquier | 2019-11-12 09:03:30 | Re: pg_waldump and PREPARE |