Greg Smith <g...@2ndquadrant.com> writes:
> The only question I'm left with after browsing the patch and staring at
> the above results is whether it makes sense to expose a pg_toast_size
> function. That would make the set available here capable of handling
> almost every situation somebody might want to know about, making this
> area completely done as I see it. In addition to being a useful
> shorthand on its own, that would then allow you to indirectly compute
> just the FSM size, which seems like an interesting number to know as
> feedback on what VACUUM is up to. It's easy enough to add, too: the
> calculate_toast_table_size code needed is already in the patch, just
> have to add another external function to expose it.
> I don't think there's any useful case for further exposing the two
> component parts of the toast size. If you're enough of a hacker to know
> what to do with those, you can certainly break them down yourself.
Hmm ... those opinions seem a bit contradictory. If you're enough of
a hacker to know what FSM is, you can subtract off the toast size for
yourself no?
I'm inclined to think that table vs. index is the right level of
abstraction for these functions, and that breaking it down further than
that isn't all that helpful. We have the bottom-level information
(per-fork relation size) available for those who really want the
details.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
