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

I found the function "table_relation_size" is only used by buffer
manager for "RELKIND_RELATION", "RELKIND_TOASTVALUE" and
"RELKIND_MATVIEW", i.e.

        case RELKIND_RELATION:
        case RELKIND_TOASTVALUE:
        case RELKIND_MATVIEW:
            {
                /*
                 * Not every table AM uses BLCKSZ wide fixed size blocks.
                 * Therefore tableam returns the size in bytes - but
for the
                 * purpose of this routine, we want the number of blocks.
                 * Therefore divide, rounding up.
                 */
                uint64        szbytes;

                szbytes = table_relation_size(relation, forkNum);

                return (szbytes + (BLCKSZ - 1)) / BLCKSZ;
            }

So using "calculate_relation_size" and "calculate_toast_table_size" in
"calculate_table_size" is easy to understand and the original logic is
simple.

On 2020-08-27 6:38 a.m., gkokolatos(at)pm(dot)me wrote:
> Hi all,
>
> this minor patch is attempting to force the use of the tableam api in dbsize where ever it is required.
>
> Apparently something similar was introduced for toast relations only. Intuitively it seems that the distinction between a table and a toast table is not needed. This patch treats tables, toast tables and materialized views equally.
>
> Regards,
> //Georgios
Best regards,
--
David

Software Engineer
Highgo Software Inc. (Canada)
www.highgo.ca