From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Dominique Devienne <ddevienne(at)gmail(dot)com> |
Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: byte-size of column values |
Date: | 2022-10-18 16:04:48 |
Message-ID: | 2655106.1666109088@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Dominique Devienne <ddevienne(at)gmail(dot)com> writes:
> Hi. I'm surprised by the result for bit(3) and char, when calling
> pg_column_size().
> Why 6, instead of 1? The doc does mention 5-8 bytes overhead, but I
> expected those for varying bit, not fixed-sized bit typed values. How
> come?
Your expectation is incorrect. Postgres always treats these types
as variable-length, whether or not the column has a length constraint.
Thus, there's always a header to store the actual length. That can
be either 1 or 4 bytes (I think the doc you are looking at might be
a little out of date on that point).
Because of the popularity of variable-width character encodings,
a column declared as N characters wide isn't necessarily a fixed
number of bytes wide, making it a lot less useful than you might
think to have optimizations for fixed-width storage. Between that
and the fact that most Postgres developers regard CHAR(N) as an
obsolete hangover from the days of punched cards, no such
optimizations have been attempted.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2022-10-18 19:18:28 | Re: Exponentiation confusion |
Previous Message | David G. Johnston | 2022-10-18 16:04:11 | Re: byte-size of column values |