On Fri, Feb 26, 2010 at 6:30 PM, Gokulakannan Somasundaram <gokul...@gmail.com> wrote: > http://archives.postgresql.org/pgsql-hackers/2008-03/msg00682.php > I think, the buy-in became difficult because of the code quality. >
Er, yeah. That's something we need to work on a bit. You should probably expect your first few attempts to just be completely wrong. Tom did give a very brief hint what was wrong with the patch but it wasn't a point by point howto either. It looks like your patch was unnecessarily complex. slot_deform_tuple/heap_deform_tuple should handle missing columns automatically already so they shouldn't need any modification. All you need to do is check in heap_form_tuple whether there's a block of nulls at the end and trim them off. If you can do this in a cpu-efficient way it would be valuable because this is a very critical path in the code. Tom's concerns about benchmarking are interesting but I'm not sure there's much we can do. We're talking about spending cpu time for space gains which is usually worthwhile. I guess the best to hope for is that on any macro benchmark there's no measurable performance penalty even with a lot of nulls at the end of a very narrow row. Or that in a microbenchmark there's a negligable penalty, perhaps under 10% for trimming 100+ trailing null columns. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
