Should TIDs be typbyval = FLOAT8PASSBYVAL to speed up CREATE INDEX CONCURRENTLY? - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Should TIDs be typbyval = FLOAT8PASSBYVAL to speed up CREATE INDEX CONCURRENTLY?
Date
Msg-id CAM3SWZTsjUMs4ypF5L57vUmSOnydr5fx2DYbxmUSnKkoJTZDJQ@mail.gmail.com
Whole thread Raw
Responses Re: Should TIDs be typbyval = FLOAT8PASSBYVAL to speed up CREATE INDEX CONCURRENTLY?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
I noticed that the TID type is cataloged as typbyval = f, despite the
fact that it is 6 bytes, and so could be made typbyval = t on 64-bit
platforms (i.e. typbyval = FLOAT8PASSBYVAL) with a little work.

This matters because a major cost during CREATE INDEX CONCURRENTLY is
a TID-based datum sort (this is probably most of the cost over and
above a conventional CREATE INDEX). Based on prior experience, I'd
guess that making the type pass-by-value on 64-bit machines would make
that sort about twice as fast. This would give CREATE INDEX
CONCURRENTLY a nice overall performance boost. SortSupport would also
help, but I would not bother with abbreviation to get some benefit on
32-bit platforms -- that would prevent 64-bit platforms from using
tuplesort's onlyKey optimization, which matters quite a bit. Given the
increasing rarity of 32-bit platforms these days, basic SortSupport
seems best.

I'm more than a little busy at the moment, so I would be happy for
someone else to write the patch. It seems worthwhile.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: creating extension including dependencies
Next
From: Michael Paquier
Date:
Subject: Re: pageinspect patch, for showing tuple data