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]  (Amit kapila <amit.kapila@huawei.com>)
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:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Deprecating RULES
Next
From: Robert Haas
Date:
Subject: Re: Deparsing DDL command strings