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 по дате отправления: