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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
