From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pgbench filler columns |
Date: | 2013-09-26 13:50:28 |
Message-ID: | 20130926135028.GA58994@tornado.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Sep 26, 2013 at 03:23:30PM +0530, Pavan Deolasee wrote:
> On Thu, Sep 26, 2013 at 2:05 PM, Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>wrote:
>
> > While looking at the compressibility of WAL files generated by pgbench,
> > which is close to 90%, I first thought its because of the "filler" column
> > in the accounts table. But a comment in pgbench.c says:
> >
> > /*
> > * Note: TPC-B requires at least 100 bytes per row, and the "filler"
> > * fields in these table declarations were intended to comply with
> > that.
> > * But because they default to NULLs, they don't actually take any
> > space.
> > * We could fix that by giving them non-null default values. However,
> > that
> > * would completely break comparability of pgbench results with prior
> > * versions. Since pgbench has never pretended to be fully TPC-B
> > * compliant anyway, we stick with the historical behavior.
> > */
> >
> > The comment about them being NULL and hence not taking up any space is
> > added by commit b7a67c2840f193f in response to this bug report:
> >
> > http://www.postgresql.org/message-id/200710170810.l9H8A76I080568@wwwmaster.postgresql.org
> >
> >
> On a more careful look, it seems the original bug report complained about
> all tables except accounts. And all other tables indeed have "filler" as
> NULL. But the way comment is written it seems as if it applies to all DDLs.
Agreed.
> Should we just fix the comment and say its applicable for all tables except
> accounts ?
Please do.
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2013-09-26 15:18:21 | Re: record identical operator |
Previous Message | Noah Misch | 2013-09-26 13:27:13 | Re: dynamic shared memory |