pgbench filler columns - Mailing list pgsql-hackers

From Pavan Deolasee
Subject pgbench filler columns
Date
Msg-id CABOikdMLx0XBMk6g7kxpoXfoPG1GcO8eFLeR5K0UqkZcVsex-g@mail.gmail.com
Whole thread Raw
Responses Re: pgbench filler columns
List pgsql-hackers
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:

But I find it otherwise. On my machine, accounts table can only fit 62 tuples in a page with default fillfactor. The following queries show that filler column is NOT NULL, but set to empty string.  I have tested on 8.2, 8.4 and master and they all show the same behavior. So I don't know if that bug report itself was wrong or if I am reading the comment wrong.

postgres=# select count(*) from pgbench_accounts where filler IS NULL;
 count 
-------
     0
(1 row)

postgres=# select count(*) from pgbench_accounts where filler = '';
 count  
--------
 100000
(1 row)


Thanks,
Pavan

--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee

pgsql-hackers by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: pgbench progress report improvements - split 3 v2
Next
From: Abhijit Menon-Sen
Date:
Subject: Re: [PATCH] bitmap indexes