From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | [RFC, POC] Don't require a NBuffer sized PrivateRefCount array of local buffer pins |
Date: | 2014-03-21 18:22:31 |
Message-ID: | 20140321182231.GA17111@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
I've been annoyed at the amount of memory used by the backend local
PrivateRefCount array for a couple of reasons:
a) The performance impact of AtEOXact_Buffers() on Assert() enabled
builds is really, really annoying.
b) On larger nodes, the L1/2/3 cache impact of randomly accessing
several megabyte big array at a high frequency is noticeable. I've
seen the access to that to be the primary (yes, really) source of
pipeline stalls.
c) On nodes with significant shared_memory the sum of the per-backend
arrays is a significant amount of memory, that could very well be
used more beneficially.
So what I have done in the attached proof of concept is to have a small
(8 currently) array of (buffer, pincount) that's searched linearly when
the refcount of a buffer is needed. When more than 8 buffers are pinned
a hashtable is used to lookup the values.
That seems to work fairly well. On the few tests I could run on my
laptop - I've done this during a flight - it's a small performance win
in all cases I could test. While saving a fair amount of memory.
Alternatively we could just get rid of the idea of tracking this per
backend, relying on tracking via resource managers...
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Attachment | Content-Type | Size |
---|---|---|
0001-Make-backend-local-tracking-of-buffer-pins-more-effi.patch | text/x-patch | 16.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2014-03-21 18:26:47 | Re: equalTupleDescs() ignores ccvalid/ccnoinherit |
Previous Message | Noah Misch | 2014-03-21 17:49:42 | Re: ALTER TABLE lock strength reduction patch is unsafe Reply-To: |