Re: Should TIDs be typbyval = FLOAT8PASSBYVAL to speed up CREATE INDEX CONCURRENTLY?
| От | Tom Lane |
|---|---|
| Тема | Re: Should TIDs be typbyval = FLOAT8PASSBYVAL to speed up CREATE INDEX CONCURRENTLY? |
| Дата | |
| Msg-id | 3120.1441684983@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Should TIDs be typbyval = FLOAT8PASSBYVAL to speed up CREATE INDEX CONCURRENTLY? (Peter Geoghegan <pg@heroku.com>) |
| Ответы |
Re: Should TIDs be typbyval = FLOAT8PASSBYVAL to speed up
CREATE INDEX CONCURRENTLY?
|
| Список | pgsql-hackers |
Peter Geoghegan <pg@heroku.com> writes:
> 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.
I'm not sure that it would be just "a little work" --- I suspect that
the idea that pass-by-val types are 1, 2, 4, or 8 bytes is embedded in
a fair number of places, including alignment macros in which any added
complexity would have a large distributed cost.
> 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).
Might be better to hack a special case right there (ie, embed TIDs into
int8s and sort the int8s) rather than try to change the type's SQL
declaration.
regards, tom lane
В списке pgsql-hackers по дате отправления: