> > 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
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.
In response to
pgsql-hackers by date
|Next:||From: Simon Riggs||Date: 2011-03-01 00:19:15|
|Subject: Re: Sync Rep v17|
|Previous:||From: Dan Ports||Date: 2011-03-01 00:03:06|
|Subject: Re: SSI bug?|