Subject: Re: PATCH: two slab-like memory allocators
To: Andres Freund <andres@anarazel.de>, Tom Lane <tgl@sss.pgh.pa.us>
References: <12622.1488216468@sss.pgh.pa.us>
 <20170227174201.yrofai7neyp6shb2@alap3.anarazel.de>
 <c7c1bb85-d1d0-05a5-4d4c-3047d6f053e7@2ndquadrant.com>
 <20170228034232.4h7ouyhxq4lbbao2@alap3.anarazel.de>
 <1240.1488254244@sss.pgh.pa.us>
 <20170228051630.3qcevakcaaa6b4ef@alap3.anarazel.de>
 <1671.1488259784@sss.pgh.pa.us>
 <20170228074420.aazv4iw6k562mnxg@alap3.anarazel.de>
 <20170228184122.extbigaer5ryrt3z@alap3.anarazel.de>
 <20170301041835.wli3viwnxr5wonfv@alap3.anarazel.de>
 <20170301042936.usv23f4iaumeyptf@alap3.anarazel.de>
Cc: Petr Jelinek <petr.jelinek@2ndquadrant.com>,
 Petr Jelinek <petr@2ndquadrant.com>, Robert Haas <robertmhaas@gmail.com>,
 John Gorman <johngorman2@gmail.com>,
 pgsql-hackers <pgsql-hackers@postgresql.org>
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Message-ID: <fa4b397e-b454-d109-990f-2f05f7e47f15@2ndquadrant.com>
Date: Thu, 2 Mar 2017 22:51:09 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <20170301042936.usv23f4iaumeyptf@alap3.anarazel.de>
Content-Type: multipart/mixed;
 boundary="------------BFD53F89E8551B41365F2999"
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

This is a multi-part message in MIME format.
--------------BFD53F89E8551B41365F2999
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

On 03/01/2017 05:29 AM, Andres Freund wrote:
> On 2017-02-28 20:18:35 -0800, Andres Freund wrote:
>> - Andres, hoping the buildfarm turns greener
>
> Oh well, that didn't work. Investigating.
>

Attaches is the last part of the patch series, rebased to current master 
and adopting the new chunk header approach. Unlike Slab, this context 
needs the whole AllocSet header (size, requested_size), and also the 
block pointer, so no padding seems to be needed.

I've tested this on x86-64 and amrv7l, and the test_decoding test suite 
passes on both.

FWIW, I'm still not entirely happy with the name "Generation". I agree 
with Andres that it's perhaps a bit too generic, but more importantly 
the name might actually be a bit obsolete. There used to be generations 
of chunks, but that's gone. Now it simply does not reuse the chunks at 
all, and frees the blocks when they get empty.

It's not entirely FIFO though, because the transactions interleave, so 
later blocks may be released first. But the "allocated close, freed 
close" is still there. So perhaps something like "TemporalSet" or 
something like that would be a better name?

Man, naming things is hard ...


regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--------------BFD53F89E8551B41365F2999
Content-Type: binary/octet-stream;
 name="gen-context.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="gen-context.patch"


--------------BFD53F89E8551B41365F2999
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

--------------BFD53F89E8551B41365F2999--