On Tue, May 6, 2014 at 12:04 AM, Robert Haas <
robertmhaas@gmail.com> wrote:
> On Mon, May 5, 2014 at 2:13 PM, Andres Freund <
andres@2ndquadrant.com> wrote:
> > On 2014-05-05 13:52:39 -0400, Robert Haas wrote:
> >> Today, I discovered that when building a btree index, the btree code
> >> uses index_form_tuple() to create an index tuple from the heap tuple,
> >> calls tuplesort_putindextuple() to copy that tuple into the sort's
> >> memory context, and then frees the original one it built. This seemed
> >> inefficient, so I wrote a patch to eliminate the tuple copying. It
> >> works by adding a function tuplesort_putindextuplevalues(), which
> >> builds the tuple in the sort's memory context and thus avoids the need
> >> for a separate copy. I'm not sure if that's the best approach, but
> >> the optimization seems wortwhile.
> >
> > Hm. It looks like we could quite easily just get rid of
> > tuplesort_putindextuple(). The hash usage doesn't look hard to convert.
>
> I glanced at that, but it wasn't obvious to me how to convert the hash
> usage. If you have an idea, I'm all ears.
I also think it's possible to have similar optimization for hash index
incase it has to spool the tuple for sorting.
In function hashbuildCallback(), when buildstate->spool is true, we
can avoid to form index tuple. To check for nulls before calling
_h_spool(), we can traverse the isnull array.
It seems converting hash index usage is not as straightforward as
btree index, but doesn't look too complex either.
