Re: pgsql: Fix a couple of bugs in MultiXactId freezing - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: pgsql: Fix a couple of bugs in MultiXactId freezing
Date
Msg-id 20131213163920.GD12902@eldon.alvh.no-ip.org
Whole thread Raw
In response to Re: pgsql: Fix a couple of bugs in MultiXactId freezing  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: pgsql: Fix a couple of bugs in MultiXactId freezing
List 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

Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: "stuck spinlock"
Next
From: Tom Lane
Date:
Subject: Re: "stuck spinlock"