Return to Answer

SELECT
  SUM(PG_COLUMN_SIZE(temp.a))     AS int_sz,
  SUM(CHARACTER_LENGTH(temp.b))   AS char_len,
  SUM(OCTET_LENGTH(temp.b))       AS oct_len,
  SUM(OCTET_LENGTH(temp.*::TEXT)) AS oct_len_total
FROM
  (SELECT * FROM test) AS temp;

SELECT
  SUM(PG_COLUMN_SIZE(t.a))     AS int_sz,
  SUM(CHARACTER_LENGTH(t.b))   AS char_len,
  SUM(OCTET_LENGTH(t.b))       AS oct_len,
  SUM(OCTET_LENGTH(t.*::TEXT)) AS oct_len_total
FROM
  test t;  -- you don't even need the alias, since the column
           -- names are unambiguous - there's only one table!
           -- However, with no alias, you do need to specify test.*!

We have 3 extra characters, but 6 extra bytes - i.e. 2 extra per character, which is to be expected from Chinese characters.

So, to answer your question, yes, your approach of using OCTET_LENGTH() is the correct one!

We have 3 extra characters, but 6 extra bytes - i.e. 2 extra per character (i.e. 3 bytes/character), which is to be expected from Chinese writing.

So, the answer to your question is, yes, your approach of using OCTET_LENGTH() is the correct one!

This is easy enough to test.

First, we check the database encoding (aka character sets - all the code below is available on the fiddle here):

This is easy enough to test - at least for the data! As @mustaccio points out, there will be further overhead for the network protocol that is used to transmit the data from the server to your client machine. The contents of this article could perhaps be adapted to see how many bytes in total are received per query.

For the data, first, we check the database encoding (aka character sets - all the code below is available on the fiddle here):