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

On 2020-09-09 12:41 a.m., gkokolatos(at)pm(dot)me wrote:
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Tuesday, 8 September 2020 22:26, David Zhang <david(dot)zhang(at)highgo(dot)ca> wrote:
>
>>
>> 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.
>>
> You are correct. This is the logic that is attempted to be applied
> in dbsize.c in this patch.
>
> So what do you think of the patch?

I would suggest to keep the original logic unless there is a bug.

--
David

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