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

From: Amit kapila <amit(dot)kapila(at)huawei(dot)com>
To: "robertmhaas(at)gmail(dot)com" <robertmhaas(at)gmail(dot)com>, "josh(at)agliodbs(dot)com" <josh(at)agliodbs(dot)com>
Cc: "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: 2012-10-13 07:54:59
Message-ID: 6C0B27F7206C9E4CA54AE035729E9C382853A391@szxeml509-mbs
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

Attachment Content-Type Size
init.sh application/octet-stream 745 bytes
sql_used.sql text/plain 279 bytes
Trim_Nulls_Perf_Report.html text/html 42.5 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2012-10-13 11:03:49 Re: Adding comments for system table/column names
Previous Message Darren Duncan 2012-10-13 05:55:52 Re: Successor of MD5 authentication, let's use SCRAM