Re: Hash partitioning.

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?