On Mon, May 5, 2014 at 2:13 PM, Andres Freund <and...@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 tested it by repeatedly executing "REINDEX INDEX
>> pgbench_accounts_pkey" on a PPC64 machine.  pgbench_accounts contains
>> 10 million records.  With unpatched master as of
>> b2f7bd72c4d3e80065725c72e85778d5f4bdfd4a, I got times of 6.159s,
>> 6.177s, and 6.201s.  With the attached patch, I got times of 5.787s,
>> 5.972s, and 5.913s, a savings of almost 5%.  Not bad considering the
>> amount of work involved.
> Yes, that's certainly worthwile. Nice.


Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to