Re: PATCH: Attempt to make dbsize a bit more consistent

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-03-17 05:35:28
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Mon, Mar 15, 2021 at 03:10:59PM +0900, Michael Paquier wrote:
> Anyway, as mentioned by other people upthread, I am not really
> convinced either that we should have more flavors of size functions,
> particularly depending on the relkind as this would be confusing for
> the end-user. pg_relation_size() can already do this job for all
> relkinds that use segment files, so it should still be able to hold
> its ground and maintain a consistent behavior with what it does
> currently.

On top of the rest of my notes, there are two more things that would
face a behavior change if making the existing functions go through
table AMs, which would scan the data in the smgr:
- After a VACUUM, the relation would be reported with a size of 0,
while that may not be the case of on-disk files yet.
- Temporary tables of other sessions would be accessible.

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.

Attachment Content-Type Size
dbsize_play.patch text/x-diff 5.8 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2021-03-17 05:57:18 Re: Getting better results from valgrind leak tracking
Previous Message Kyotaro Horiguchi 2021-03-17 05:25:07 Re: libpq debug log