Re: speedup tidbitmap patch: cache page

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: speedup tidbitmap patch: cache page
Дата
Msg-id CAApHDvr8f9UnfWZpVY0OEfd_Eoxa7Br_29j+fkZQ3-Qi=fU36w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: speedup tidbitmap patch: cache page  (Teodor Sigaev <teodor@sigaev.ru>)
Ответы Re: speedup tidbitmap patch: cache page  (Andres Freund <andres@2ndquadrant.com>)
Список pgsql-hackers
On 24 December 2014 at 00:24, Teodor Sigaev <teodor@sigaev.ru> wrote:
I've also attached some benchmark results using your original table from
up-thread. It seems that the caching if the page was seen as lossy is not much
of a help in this test case. Did you find another one where you saw some better
gains?

All what I found is about 0.5%...  v3 contains your comments but it doesn't use
lossy_page cache.


Ok, I've performed some more benchmarks (attached) using your original table. I'm thinking the v2.3 version is not worth the extra complexity. It seems the extra caching in v2.3, going by my benchmarks, is more likely to add overhead than save from hash lookups. 

With the query used in my tests using v2.3 I didn't even see a speed up with 5 million records and 64KB of work_mem.

So I think v3 is the one to go with, and I can't see any problems with it, so I'm marking it as ready for committer.

Nice work

Kind Regards

David Rowley
Вложения

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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: [REVIEW] Re: Compression of full-page-writes
Следующее
От: Michael Paquier
Дата:
Сообщение: Moving RestoreBlockImage from xlogreader.c to xlogutils.c