From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | Jamie Martin <jameisonb(at)yahoo(dot)com> |
Cc: | Amit Kapila <amit(dot)kapila(at)huawei(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)2ndquadrant(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Kevin Grittner <kgrittn(at)mail(dot)com>, "<robertmhaas(at)gmail(dot)com>" <robertmhaas(at)gmail(dot)com>, "<pgsql-hackers(at)postgresql(dot)org>" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: patch submission: truncate trailing nulls from heap rows to reduce the size of the null bitmap [Review] |
Date: | 2013-07-08 18:25:51 |
Message-ID: | 51DB042F.6070400@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
From | Date | Subject | |
---|---|---|---|
Next Message | ivan babrou | 2013-07-08 18:31:23 | Re: Millisecond-precision connect_timeout for libpq |
Previous Message | Pavel Stehule | 2013-07-08 17:54:42 | Re: Improving avg performance for numeric |