From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: avoiding tuple copying in btree index builds |
Date: | 2014-05-05 18:13:38 |
Message-ID: | 20140505181338.GE17909@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
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 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.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-05-05 18:15:58 | Re: Recursive ReceiveSharedInvalidMessages not safe |
Previous Message | Peter Geoghegan | 2014-05-05 17:58:57 | Re: 9.4 release notes |