On Thu, Apr 26, 2012 at 8:27 AM, Simon Riggs <si...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
