| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | gkokolatos(at)pm(dot)me |
| Cc: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Soumyadeep Chakraborty <soumyadeep2007(at)gmail(dot)com>, Daniel Gustafsson <daniel(at)yesql(dot)se>, David Zhang <david(dot)zhang(at)highgo(dot)ca>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: PATCH: Attempt to make dbsize a bit more consistent |
| Date: | 2021-04-08 08:04:35 |
| Message-ID: | YG636TVWk3C+Sfm6@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Mar 17, 2021 at 02:35:28PM +0900, Michael Paquier wrote:
> So we would likely want a separate function. Another possibility,
> which I find tempting, would be to push down the calculation logic
> relying on physical files down to the table AM themselves with a new
> dedicated callback (relation_size_physical?), as it seems to me that
> the most important thing users want to know with this set of functions
> is how much physical space is being consumed at one given point in
> time. Attached is a small prototype I was just playing with.
Thinking more about that, I'd be rather in favor of having a new table
AM callback to let the AM measure the size of physical files, and make
the business of dbsize.c fall under that. It is clear that this needs
more work, so I have marked it as returned with feedback.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2021-04-08 08:10:43 | Re: Support for NSS as a libpq TLS backend |
| Previous Message | Bharath Rupireddy | 2021-04-08 08:00:58 | Re: Can we remove extra memset in BloomInitPage, GinInitPage and SpGistInitPage when we have it in PageInit? |