Re: Proposal for Null Bitmap Optimization(for TrailingNULLs) - Mailing list pgsql-hackers

From Gokulakannan Somasundaram
Subject Re: Proposal for Null Bitmap Optimization(for TrailingNULLs)
Date
Msg-id 9362e74e0712191000t4257eea7kabcf97a1d99ef5f5@mail.gmail.com
Whole thread Raw
In response to Re: Proposal for Null Bitmap Optimization(for TrailingNULLs)  (Gregory Stark <stark@enterprisedb.com>)
Responses Re: Proposal for Null Bitmap Optimization(for TrailingNULLs)
List pgsql-hackers
I have submitted the first working patch for the trailing null optimization. It currently does the following
a) Doesn't store the null bitmap, if the heap tuple / index tuple contains only trailing nulls
b) In Heap Tuple, the trailing nulls won't occupy space in the null bitmap.

The General design is like this
a) After checking for trailing nulls, i reduce the number of attributes field, which gets stored in each heap tuple.
b) For Index, i have changed the Index_form_tuple to store the unaligned total size in the size mask. While navigating through the index tuple, if the offset exceeds the unaligned total size stored, then a null is returned

Please review it and provide suggestions.

 
>
> I doubt you have fixed it; I doubt it's *possible* to fix it without
> significant rejiggering of IndexTuple representation.  The problem is
> that IndexTuple lacks a number-of-fields field, so there is no place
> to indicate how many null bitmap bits you have actually stored.

Actually i have made one change to the structure of IndexTupleData. Instead of storing the Aligned size in the size mask, i have stored the  un-aligned size. I am storing the size before the final MAXALIGN. The interface remains un-changed. IndexTupleSize does a MAXALIGN before returning the size value. so the interface remains un-changed.  The advantage of storing the un-aligned size is that we can get both aligned size and un-aligned size(As you may know). I have created two more macros to return the un-aligned size.

 
  

> I would suggest forgetting that part and submitting the part that
> has some chance of getting accepted.

Actually i want to submit the patch, which is best according to me.
 


I suspect there's also an awkward case that *does* need to handled when you
insert a tuple which has a null column which you're leaving out of the tuple
but which appears in an index. You would have to make sure that the index
tuple has that datum listed as NULL even though it's entirely missing from the
heap tuple.

Actually this is taken care because of your suggestion. When you add a new column, it doesn't appear in the heaptuple, but if you create an index on that column afterwards, the case is handled. There is a field in HeapTuple, which mentions the number of attributes in the tuple. If we are requesting for attribute numbers greater than this number, it is returned as null. So that problem was taken care.


--
Thanks,
Gokul.
CertoSQL Project,
Allied Solution Group.
(www.alliedgroups.com)
Attachment

pgsql-hackers by date:

Previous
From: Mark Mielke
Date:
Subject: Re: Sorting Improvements for 8.4
Next
From: Jeff Davis
Date:
Subject: Re: Sorting Improvements for 8.4