Tue, 26 Jun 2012 17:04:42 -0400 Robert Haas wrote:
> I see you posted up a follow-up email asking Tom what he had in mind.
> Personally, I don't think this needs incredibly complicated testing.
> I think you should just test a workload involving inserting and/or
> updating rows with lots of trailing NULL columns, and then another
> workload with a table of similar width that... doesn't. If we can't
> find a regression - or, better, we find a win in one or both cases -
> then I think we're done here.
As per the last discussion for this patch, performance data needs to be provided before this patch's Review can proceed further.
So as per your suggestion and from the discussions about this patch, I have collected the performance data as below:
Results are taken with following configuration.
1. Schema - UNLOGGED TABLE with 2,000,000 records having all columns are INT type.
2. shared_buffers = 10GB
3. All the performance result are taken with single connection.
4. Performance is collected for INSERT operation (insert into temptable select * from inittable)
Platform details:
Operating System: Suse-Linux 10.2 x86_64
Hardware : 4 core (Intel(R) Xeon(R) CPU L5408 @ 2.13GHz)
RAM : 24GB
Documents Attached:
init.sh : Which will create the schema
sql_used.sql : sql's used for taking results
Trim_Nulls_Perf_Report.html : Performance data
Observations from Performance Results
------------------------------------------------
1. There is no performance change for cloumns that have all valid values(non- NULLs).
2. There is a visible performance increase when number of columns containing NULLS are more than > 60~70% in table have large number of columns.
3. There are visible space savings when number of columns containing NULLS are more than > 60~70% in table have large number of columns.
Let me know if there is more performance data needs to be collected for this patch?
With Regards,
Amit Kapila.
