Re: patch submission: truncate trailing nulls from heap rows to reduce the size of the null bitmap [Review] - Mailing list pgsql-hackers
| From | Amit kapila |
|---|---|
| Subject | Re: patch submission: truncate trailing nulls from heap rows to reduce the size of the null bitmap [Review] |
| Date | |
| Msg-id | 6C0B27F7206C9E4CA54AE035729E9C382853AA40@szxeml509-mbs Whole thread Raw |
| In response to | Re: patch submission: truncate trailing nulls from heap rows to reduce the size of the null bitmap [Review] (Amit kapila <amit.kapila@huawei.com>) |
| Responses |
Re: patch submission: truncate trailing nulls from heap rows to
reduce the size of the null bitmap [Review]
|
| List | pgsql-hackers |
On Saturday, October 13, 2012 1:24 PM Amit kapila wrote:
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
Further to Performance data, I have completed the review of the Patch.
Basic stuff:
------------
- Rebase of Patch is required.
As heap_fill_tuple function prototype is moved to different file [htup.h to htup_details.h]
- Compiles cleanly without any errors/warnings
- Regression tests pass.
Code Review comments:
---------------------
1. There is possibility of memory growth in case of toast table, if trailing toasted columns are updated to NULLs;
i.e. In Function toast_insert_or_update, for tuples when 'need_change' variable is true, numAttrs are modified to last
nonnull column values,
and in old tuple de-toasted columns are not getting freed, if this repeats for more number of tuples there is
chanceof out of memory.
if ( need_change)
{
numAttrs = lastNonNullValOffset + 1;
....
}
if (need_delold)
for (i = 0; i < numAttrs; i++) <== Tailing toasted value wouldn't be freed as updated to NULL and
numAttrsis modified to smaller value.
if (toast_delold[i])
toast_delete_datum(rel, toast_oldvalues[i]);
2. Comments need to updated in following functions; how ending null columns are skipped in header part.
heap_fill_tuple - function header
heap_form_tuple, heap_form_minimal_tuple, heap_form_minimal_tuple.
3. Why following change is required in function toast_flatten_tuple_attribute
- numAttrs = tupleDesc->natts;
+ numAttrs = HeapTupleHeaderGetNatts(olddata);
Detailed Performance Report for Insert and Update Operations is attached with this mail.
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
largenumber of columns.
3. There are visible space savings when number of columns containing NULLS are more than > 60~70% in table have large
numberof columns.
With Regards,
Amit Kapila.
Attachment
pgsql-hackers by date: