2013/6/27 Nicolas Barbier <nicolas.barb...@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? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
