Re: patch submission: truncate trailing nulls from heap rows to reduce the size of the null bitmap [Review]

Josh Berkus <josh@agliodbs.com>

From: Josh Berkus <josh@agliodbs.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Jamie Martin <jameisonb@yahoo.com>, Amit Kapila <amit.kapila@huawei.com>, Andres Freund <andres@2ndquadrant.com>, Craig Ringer <craig@2ndquadrant.com>, Noah Misch <noah@leadboat.com>, Simon Riggs <simon@2ndquadrant.com>, Kevin Grittner <kgrittn@mail.com>, "<robertmhaas@gmail.com>" <robertmhaas@gmail.com>, "<pgsql-hackers@postgresql.org>" <pgsql-hackers@postgresql.org>
Date: 2013-06-27T21:12:29Z
Lists: pgsql-hackers
On 06/27/2013 11:11 AM, Tom Lane wrote:
> AFAICS, the threshold question here is whether the patch helps usefully
> for tables with typical numbers of columns (ie, not 800 ;-)), and

I wouldn't expect it to help at all for < 50 columns, and probably not
measurably below 200.

> doesn't hurt materially in any common scenario.  If it does, I think

Yeah, I think that's be bigger question.  Ok, I'll start working on a
new test case.  Here's my thinking on performance tests:

1. run pgbench 10 times both with and without the patch.  See if there's
any measurable difference.  There should not be.

2. Run with/without comparisons for the following scenarios:

Each table would have a SERIAL pk, a timestamp, and:

Chains of booleans:
# attributes		NULL probability
	16		0% 	50%	90%
	128		0% 	50%	90%
	512		0%	50%	90%

Chains of text:
	16		0%	50%	90%
	256		0%	50%	90%

... for 100,000 rows each.

Comparisons would include:

1) table size before and after testing
2) time required to read 1000 rows, by key
3) time required to read rows with each of
	100 random column positions = some value
4) time required to insert 1000 rows
5) time required to update 1000 rows

Geez, I feel tired just thinking about it.  Jamie, can your team do any
of this?

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com


Commits

  1. Don't assume that a tuple's header size is unchanged during toasting.