Skip site navigation (1) Skip section navigation (2)

Re: WIP: cross column correlation ...

From: Rod Taylor <rod(dot)taylor(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL - Hans-Jürgen Schönig <postgres(at)cybertec(dot)at>, pgsql-hackers Hackers <pgsql-hackers(at)postgresql(dot)org>, Boszormenyi Zoltan <zb(at)cybertec(dot)at>
Subject: Re: WIP: cross column correlation ...
Date: 2011-03-01 00:18:43
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
> > 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 RiggsDate: 2011-03-01 00:19:15
Subject: Re: Sync Rep v17
Previous:From: Dan PortsDate: 2011-03-01 00:03:06
Subject: Re: SSI bug?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group