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
-
Don't assume that a tuple's header size is unchanged during toasting.
- 039680affb1b 9.2.0 cited