Skip site navigation (1) Skip section navigation (2)

Re: A thought on Index Organized Tables

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Gokulakannan Somasundaram <gokul007(at)gmail(dot)com>
Cc: pgsql-hackers list <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: A thought on Index Organized Tables
Date: 2010-02-26 19:59:57
Message-ID: 407d949e1002261159q45344720jba3448e8f2fa8397@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Fri, Feb 26, 2010 at 6:30 PM, Gokulakannan Somasundaram
<gokul007(at)gmail(dot)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

In response to

pgsql-hackers by date

Next:From: Josh BerkusDate: 2010-02-26 20:02:08
Subject: Re: Re: Hot Standby query cancellation and Streaming Replication integration
Previous:From: Tom LaneDate: 2010-02-26 19:57:56
Subject: Re: Avoiding bad prepared-statement plans.

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group