Re: pgsql: Fix a couple of bugs in MultiXactId freezing
От | Alvaro Herrera |
---|---|
Тема | Re: pgsql: Fix a couple of bugs in MultiXactId freezing |
Дата | |
Msg-id | 20131213163920.GD12902@eldon.alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: pgsql: Fix a couple of bugs in MultiXactId freezing (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: pgsql: Fix a couple of bugs in MultiXactId freezing
|
Список | pgsql-hackers |
Alvaro Herrera wrote: > So I think this is the only remaining issue to make this patch > committable (I will address the other points in Andres' email.) Since > there has been no other feedback on this thread, Andres and I discussed > the cache issue a bit over IM and we seem to agree that a patch to > revamp the cache should be a fairly localized change that could be > applied on both 9.3 and master, separately from this fix. Doing cache > deletion seems more invasive, and not provide better performance anyway. Here's cache code with LRU superpowers (ahem.) I settled on 256 as number of entries because it's in the same ballpark as MaxHeapTuplesPerPage which seems a reasonable guideline to follow. I considered the idea of avoiding palloc/pfree for cache entries entirely, instead storing them in a static array which is referenced from the dlist; unfortunately that doesn't work because each cache entry is variable size, depending on number of members. We could try to work around that and allocate a large shared array for members, but that starts to smell of over-engineering, so I punted. I was going to 'perf' this, but then found out that I need to compile my own linux-tools package for a home-compiled kernel ATM. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Вложения
В списке pgsql-hackers по дате отправления: