Re: Performance degradation in Bitmapscan (commit 75ae538bc3168bf44475240d4e0487ee2f3bb376)

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Performance degradation in Bitmapscan (commit 75ae538bc3168bf44475240d4e0487ee2f3bb376)
Дата
Msg-id 20161123083351.5vramz52nmdokhzz@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Performance degradation in Bitmapscan (commit 75ae538bc3168bf44475240d4e0487ee2f3bb376)  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Performance degradation in Bitmapscan (commit 75ae538bc3168bf44475240d4e0487ee2f3bb376)  (Dilip Kumar <dilipbalaut@gmail.com>)
Re: Performance degradation in Bitmapscan (commit 75ae538bc3168bf44475240d4e0487ee2f3bb376)  (Robert Haas <robertmhaas@gmail.com>)
Re: [HACKERS] Performance degradation in Bitmapscan (commit 75ae538bc3168bf44475240d4e0487ee2f3bb376)  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On 2016-11-18 08:00:40 -0500, Robert Haas wrote:
> On Tue, Nov 15, 2016 at 2:28 PM, Andres Freund <andres@anarazel.de> wrote:
> > I've a working fix for this, and for a similar issue Robert found. I'm
> > still playing around with it, but basically the fix is to make the
> > growth policy a bit more adaptive.
>
> Any chance you can post a patch soon?

Here's my WIP series addressing this and related problems. With this
we're again noticeably faster than the dynahash implementation, in both
the case here, and the query you brought up over IM.

This definitely needs some more TLC, but the general approach seems
good. I particularly like that it apparently allows us to increase the
default fillfactor without much downside according to my measurements.

Greetings,

Andres Freund

Вложения

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

Предыдущее
От: Vladimir Svedov
Дата:
Сообщение: Re: postgres 9.3 postgres_fdw ::LOG: could not receive data from client: Connection reset by peer
Следующее
От: Magnus Hagander
Дата:
Сообщение: Re: [RFC] Should we fix postmaster to avoid slow shutdown?