Re: reduce null bitmap size

Lists: pgsql-hackers
From: yamt(at)mwd(dot)biglobe(dot)ne(dot)jp (YAMAMOTO Takashi)
To: pgsql-hackers(at)postgresql(dot)org
Subject: reduce null bitmap size
Date: 2011-11-06 23:08:07
Message-ID: 20111106230807.7A3FA14A439@mail.netbsd.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

hi,

how about making heap_form_tuple and its variants use smaller natts for
tuples whose trailing columns are NULL? depending on the schema, it can
save considerable space.
the most of code are ready to deal with such tuples for ALTER TABLE ADD
COLUMN anyway. (except system catalogs?)

YAMAMOTO Takashi


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: yamt(at)mwd(dot)biglobe(dot)ne(dot)jp (YAMAMOTO Takashi)
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: reduce null bitmap size
Date: 2011-11-09 16:39:15
Message-ID: 15115.1320856755@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

yamt(at)mwd(dot)biglobe(dot)ne(dot)jp (YAMAMOTO Takashi) writes:
> how about making heap_form_tuple and its variants use smaller natts for
> tuples whose trailing columns are NULL?

This idea has been proposed before, and rejected on the basis that it's
unlikely to save enough to be worth the cycles needed to check for the
case. Keep in mind that you aren't going to save anything at all unless
the bitmap length decreases across a MAXALIGN boundary.

regards, tom lane


From: yamt(at)mwd(dot)biglobe(dot)ne(dot)jp (YAMAMOTO Takashi)
To: tgl(at)sss(dot)pgh(dot)pa(dot)us
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: reduce null bitmap size
Date: 2011-11-11 09:26:53
Message-ID: 20111111092654.15F4914A2AD@mail.netbsd.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

hi,

> yamt(at)mwd(dot)biglobe(dot)ne(dot)jp (YAMAMOTO Takashi) writes:
>> how about making heap_form_tuple and its variants use smaller natts for
>> tuples whose trailing columns are NULL?
>
> This idea has been proposed before, and rejected on the basis that it's
> unlikely to save enough to be worth the cycles needed to check for the
> case. Keep in mind that you aren't going to save anything at all unless
> the bitmap length decreases across a MAXALIGN boundary.

but it also means that, if one-bit descrease happens to cross the boundary,
you can save a MAXALIGN, right?

btw, while playing with this, i noticed that pg_column_size+rowtype+aggregate
produces unstable results. i guess it's because when nodeAgg handles
grp_firstTuple, the tuple is converted to a short varlena. i don't know
if it can be a real problem than just a weird looking.

YAMAMOTO Takashi

test=# create table t (i int);
CREATE TABLE
test=# insert into t values (1),(2),(3);
INSERT 0 3
test=# select pg_column_size(t.*) from t;
pg_column_size
----------------
28
28
28
(3 rows)

test=# select string_agg(pg_column_size(t.*)::text,',') from t;
string_agg
------------
25,28,28
(1 row)

test=#

>
> regards, tom lane
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers