Bruce Momjian <[EMAIL PROTECTED]> writes:Is the issue of many columns in a tuple the same issue as a SELECT having many columns?
I believe all the same inefficiencies need to be fixed whichever way you look at it. Probably "many columns in SELECT" is the more accurate description though.
Together with the recent discussions about attribute reordering, it'd make sense, if we have a "resentation order" different from the actual physical tuple layout, that the table starts with all variable length fields at the end. This would give a better utilization of attribute offset caching.
Don't know though, if this counts for much of the suffering.
Jan
regards, tom lane
---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives?
http://archives.postgresql.org
-- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== [EMAIL PROTECTED] #
---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
