From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | avoiding tuple copying in btree index builds |
Date: | 2014-05-05 17:52:39 |
Message-ID: | CA+TgmobG=TfNiZFnVgmFqan9SS_rESCrwLAxqhcfLu+VXqQtzA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
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.
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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Attachment | Content-Type | Size |
---|---|---|
avoid-btree-build-tuple-copy-v1.patch | text/x-patch | 4.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2014-05-05 17:53:41 | Re: New and interesting replication issues with 9.2.8 sync rep |
Previous Message | Fabrízio de Royes Mello | 2014-05-05 17:52:22 | Re: TABLESPACE and directory for Foreign tables? |