> > But it's not the same as tracking *sections of a table*. > > I dunno. I imagine if you have a "section" of a table in different > storage than other sections, you created a tablespace and moved the > partition holding that section there. Otherwise, how do you prevent the > tuples from moving to other "sections"? (We don't really have a concept > of "sections" of a table.) > > Section could be as simple as being on the inner or outer part of a single disk, or as complicated as being on the SSD cache of a spinning disk, or in the multi-gigabyte cache on the raid card or SAN due to being consistently accessed.
Section is the wrong word. If primary key values under 10 million are consistently accessed, they will be cached even if they do get moved through the structure. Values over 10M may be fast if on the same page as the other value but probably aren't. This is very evident when dealing with time based data in what can be a very large structure. 1% may be very hot and in memory while 99% is not. Partitioning only helps if you can predict what will be hot in the future. Sometimes an outside source (world events) impacts what section of the structure is hot. regards, Rod
