Horton

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

Josh Berkus <josh@agliodbs.com>

View thread View on postgr.es
From: Josh Berkus <josh@agliodbs.com>
To: Jamie Martin <jameisonb@yahoo.com>
Cc: Amit Kapila <amit.kapila@huawei.com>, Tom Lane <tgl@sss.pgh.pa.us>, 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-07-08T18:25:51Z
Lists: pgsql-hackers 
On 06/26/2013 07:05 AM, Jamie Martin wrote:
> FYI I submitted a slightly modified patch since Amit's measurements that is slightly faster. 

Yes.  My perspective is that this is a worthwhile optimization for a
minority, but fairly well-known, use case, provided that it doesn't
negatively impact any other, more common use case.  Potential cases
where I can see negative impact are:

A) normal table with a few, mostly non-null columns (recent pgbench
testing seems to have validated no measurable impact).

B) table with many (400+) mostly non-null columns

C) table with many (400+) mostly null columns, where column #390 was
null and gets updated to a not null value

I don't *think* that Jamie's performance tests have really addressed the
above cases.  However, do people agree that if performance on the patch
passes for all of A, B and C, then it's OK to apply?

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

Commits

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