Re: avoiding tuple copying in btree index builds

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: avoiding tuple copying in btree index builds
Date: 2014-06-17 14:08:31
Message-ID: 17184.1403014111@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Jun 16, 2014 at 8:10 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> On a micro-optimization level, it might be worth passing the TID as
>> ItemPointer not ItemPointerData (ie, pass a pointer until we get to
>> the point of actually inserting the TID into the index tuple).
>> I'm not sure that copying odd-size structs should be assumed to be
>> efficient.

> Yeah, true. Checking existing precedent, it looks like we usually
> pass ItemPointer rather than ItemPointerData, so it's probably a good
> idea to do this that way too for reasons of style if nothing else. I
> kind of wonder whether it's really more efficient to pass an 8-byte
> pointer to a 6-byte structure than to just pass the structure itself,
> but it might be.

The pointer will certainly be passed in a register, or whatever passes for
registers on the particular machine architecture. Weird-size structs,
though, tend to have arcane and not-so-efficient rules for being passed
by value. It's not unlikely that what the compiler will do under the hood
is pass a pointer anyhow, and then do a memcpy to make a local copy in
the called function.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kohei KaiGai 2014-06-17 14:12:59 Re: [v9.5] Custom Plan API
Previous Message Tom Lane 2014-06-17 14:02:51 Re: UPDATE SET (a,b,c) = (SELECT ...) versus rules