Dominique Devienne writes:
> On Tue, Oct 18, 2022 at 6:04 PM Tom Lane wrote:
>> 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).
> Even the doc on v15 (or devel) stil
On Tue, Oct 18, 2022 at 6:04 PM Tom Lane wrote:
> Dominique Devienne writes:
> > I'm surprised by the result for bit(3) and char
> > The doc does mention 5-8 bytes overhead, but I expected
> > those for varying bit, not fixed-sized bit typed values.
>
> Your expectation is incorrect. Postgres al
On Tue, Oct 18, 2022 at 6:04 PM David G. Johnston
wrote:
> On Tue, Oct 18, 2022 at 8:53 AM Dominique Devienne
> wrote:
>> I'm surprised by the result for bit(3) and char, when calling
>> pg_column_size().
> The base type is what matters, if the length of the actual type is a parameter
> (the (
Dominique Devienne 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.
On Tue, Oct 18, 2022 at 8:53 AM Dominique Devienne
wrote:
> 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?
