| From: | Nicolas Barbier <nicolas(dot)barbier(at)gmail(dot)com> |
|---|---|
| To: | Claudio Freire <klaussfreire(at)gmail(dot)com>, Yuri Levinsky <yuril(at)celltick(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Christopher Browne <cbbrowne(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, PostgreSQL Mailing Lists <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Hash partitioning. |
| Date: | 2013-06-27 09:24:33 |
| Message-ID: | CAP-rdTaqgc9RDtiCLL95wK-7xUNOFRF1KHbmj+4yTJyU=JeOtA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
2013/6/27 Nicolas Barbier <nicolas(dot)barbier(at)gmail(dot)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?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeevan Chalke | 2013-06-27 09:29:01 | Re: checking variadic "any" argument in parser - should be array |
| Previous Message | Nicolas Barbier | 2013-06-27 09:12:43 | Re: Hash partitioning. |