Stephan Szabo escribió: > On Wed, 21 Feb 2007, Martijn van Oosterhout wrote: > > > On Wed, Feb 21, 2007 at 12:06:30PM -0500, Phil Currier wrote: > > > Well, for two reasons: > > > > > > 1) If you have a table with one very-frequently-accessed varchar() > > > column and several not-frequently-accessed int columns, it might > > > actually make sense to put the varchar column first. The system won't > > > always be able to make the most intelligent decision about table > > > layout. > > > > Umm, the point of the exercise is that if you know there are int > > columns, then you can skip over them, whereas you can never skip over a > > varchar column. So there isn't really any situation where it would be > > better to put the varchar first. > > IIRC, in the first message in this thread, or another recent thread of > this type, someone tried a reordering example with alternating > smallints and varchar() and found that the leftmost varchar was > actually slower to access after reordering, so I'm not sure that we can > say there isn't a situation where it would affect things.
Offsets are cached in tuple accesses, but the caching is obviously disabled for all attributes past any variable-length attribute. So if you put a varlena attr in front, caching is completely disabled for all attrs (but that first one). The automatic reordering algorithm must put all fixed-len attrs at the front, so that their offets (and that of the first variable length attr) can be cached. Did I miss something in what you were trying to say? I assume you must already know this. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly