Re: avoiding tuple copying in btree index builds - Mailing list pgsql-hackers

From Robert Haas
Subject Re: avoiding tuple copying in btree index builds
Date
Msg-id CA+TgmoYjrQwTPCVkz=p8SnAwsB8OHwub3sFh_bud7CcAN4huNA@mail.gmail.com
Whole thread Raw
In response to Re: avoiding tuple copying in btree index builds  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, Jun 17, 2014 at 10:08 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Mon, Jun 16, 2014 at 8:10 PM, Tom Lane <tgl@sss.pgh.pa.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.

OK, committed with the suggested changes.

(Thanks to Abhijit for pinging me about this, and more generally for
his active and effective management of this CommitFest!)

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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: "RETURNING PRIMARY KEY" syntax extension
Next
From: Robert Haas
Date:
Subject: Re: WAL format and API changes (9.5)