Hi,
Back from the holiday times. I have tried to present the proof, that the
null bitmap was absent in the table with the trailing nulls.
On Dec 22, 2007 4:43 AM, Decibel! [EMAIL PROTECTED] wrote:
On Dec 20, 2007, at 2:36 AM, Gokulakannan Somasundaram wrote:
I checked it by creating a
On Dec 20, 2007, at 2:36 AM, Gokulakannan Somasundaram wrote:
I checked it by creating a table with 10 columns on a 32 bit
machine. i inserted 100,000 rows with trailing nulls and i observed
savings of 400Kbytes.
That doesn't really tell us anything... how big was the table
originally?
Thanks for the suggestions. I am re-submitting the patch in contextual diff
format.
As far as storage savings are concened, the patch claims whatever is stated.
I checked it by creating a table with 10 columns on a 32 bit machine. i
inserted 100,000 rows with trailing nulls and i observed savings
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
Gokulakannan Somasundaram wrote:
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.
That's not an attitude that is likely to succeed - you need to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 19 Dec 2007 13:46:15 -0500
Andrew Dunstan [EMAIL PROTECTED] wrote:
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
Gokulakannan Somasundaram [EMAIL PROTECTED] writes:
I have currently completed the following
a) If there are only trailing nulls in the heap, no null-bitmap gets stored
b) If there are trailing nulls in addition to nulls inbetween values in the
heap, then the trailing nulls are not added to
Simon Riggs [EMAIL PROTECTED] writes:
On Mon, 2007-12-17 at 08:47 -0500, Andrew Dunstan wrote:
This strikes me as such a corner case that it's likely not to be worth it.
If you really want to save space along these lines, one better place to
start might be mutable with column ordering -
Hi,
I made the fix and tested it today. It involved some 10-15 lines of code
change. I will mail it tomorrow. Feel free to give suggestions on making the
fix more maintainable.
I have followed Gregory's advice in the fix - Instead of changing the
slot_deform_tuple, i have reduced the number
