Re: pgbench filler columns - Mailing list pgsql-hackers

From Noah Misch
Subject Re: pgbench filler columns
Date
Msg-id 20130926135028.GA58994@tornado.leadboat.com
Whole thread Raw
In response to Re: pgbench filler columns  (Pavan Deolasee <pavan.deolasee@gmail.com>)
Responses Re: pgbench filler columns
List 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.deolasee@gmail.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



pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: dynamic shared memory
Next
From: Robert Haas
Date:
Subject: Re: record identical operator