2013/6/27 Nicolas Barbier <nicolas.barbier@gmail.com>:
> When each index requires one extra I/O (because each index is
> one level taller), that is 50 extra I/Os. In the partitioned case,
> each index would require the normal smaller amount of I/Os.
[..]
> Using those other indexes (both for look-ups and
> updates) in the non-partitioned case, will therefore pull a huge
> portion of each index into cache (because of the “random distribution”
> of the non-date data). In the partitioned case, more cache can be
> spent on the indexes that correspond to the “hot partitions.”
It seems that the system described by Claudio fixes this problem another way:
Claudio wrote:
> Now I just have two indices. One that indexes only hot tuples, it's
> very heavily queried and works blazingly fast, and one that indexes by
> (hotness, key).
Yuri, maybe that is something you should investigate instead of partitioning?
Nicolas
--
A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?