Re: Hash partitioning.

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: Hash partitioning.
Дата
Msg-id CAMkU=1yFnDV3qSH2PejLkjP6SBozjpTceOYD6a8c9TuzfAdoTQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Hash partitioning.  (Claudio Freire <klaussfreire@gmail.com>)
Ответы Re: Hash partitioning.  (Claudio Freire <klaussfreire@gmail.com>)
Список pgsql-hackers
On Wed, Jun 26, 2013 at 11:14 AM, Claudio Freire <klaussfreire@gmail.com> 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). I include the hotness value on the query, and still
works quite fast enough. Luckily, I know things become cold after an
update to mark them cold, so I can do that. I included hotness on the
index to cluster updates on the hot part of the index, but I could
have just used a regular index and paid a small price on the updates.
Indeed, for a while it worked without the hotness, and there was no
significant trouble. I later found out that WAL bandwidth was
noticeably decreased when I added that hotness column, so I did, helps
a bit with replication. Has worked ever since.


I'm surprised that clustering updates into the hot part of the index, without also clustering them it into a hot part of the table heap, works well enough to make a difference.  Does clustering in the table just come naturally under your usage patterns?

 Cheers,

Jeff

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jeff Janes
Дата:
Сообщение: Re: Hash partitioning.
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: checking variadic "any" argument in parser - should be array