On Thu, Apr 26, 2012 at 8:27 AM, Simon Riggs 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

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 10 of 28 | next ›
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedApr 17, '12 at 4:23p
activeAug 10, '12 at 12:06a
posts28
users8
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2021 Grokbase