On Thu, Apr 26, 2012 at 8:27 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> The source table had 5 integer columns, and was populated with 10 million
>> rows.
...
>> 2) target has all nullable columns, only the first column is set: the
>> patch was slightly faster
...
>> By slightly faster I'm talking on order of 10 nanoseconds per row.
>>
>> I think #2 is explained by the reduction in loop iterations in
>> heap_fill_tuple().
>
> I see this as a useful use case that I have come across in a few
> cases, most typically associated with very large databases.
Indeed, if this result holds up then I think that would be pretty
convincing evidence. But I'm pretty skeptical. You're talking about
five bitmap tests in the middle of a loop involving much more
expensive steps. Can we see the raw numbers and the actual test case?
What I think would be strong evidence it's a real effect is if you
repeat the comparison with larger numbers and see the speedup scale
up. For instance if you create a table with 100 nullable columns and
one non-null column value stored in various columns. Is the difference
between the runtimes for the 95th column and 100th column doubled when
you compare the 90th and 100th column cases? And is it doubled again
when you compare the 80th column and the 100th column cases? (Off the
top of my head I think the null bitmap would take the same storage
space for those four)
--
greg
