Re: RFC: Packing the buffer lookup table

2025-02-05 Thread Matthias van de Meent
On Wed, 5 Feb 2025 at 02:14, Andres Freund wrote: > > Hi, > > On 2025-01-30 08:48:56 +0100, Matthias van de Meent wrote: > > Some time ago I noticed that every buffer table entry is quite large at 40 > > bytes (+8): 16 bytes of HASHELEMENT header (of which the last 4 bytes are > > padding), 20 byt

Re: RFC: Packing the buffer lookup table

2025-02-05 Thread Matthias van de Meent
On Wed, 5 Feb 2025 at 02:22, Andres Freund wrote: > > Hi, > > On 2025-02-04 19:58:36 +0100, Matthias van de Meent wrote: > > On Thu, 30 Jan 2025 at 08:48, Matthias van de Meent > > wrote: > > > > > > Together that results in the following prototype patchset. > > > > Here's an alternative patch, w

Re: RFC: Packing the buffer lookup table

2025-02-04 Thread Andres Freund
Hi, On 2025-02-04 19:58:36 +0100, Matthias van de Meent wrote: > On Thu, 30 Jan 2025 at 08:48, Matthias van de Meent > wrote: > > > > Together that results in the following prototype patchset. > > Here's an alternative patch, which replaces dynahash in the buffer > lookup table with an open-code

Re: RFC: Packing the buffer lookup table

2025-02-04 Thread Andres Freund
Hi, On 2025-01-30 08:48:56 +0100, Matthias van de Meent wrote: > Some time ago I noticed that every buffer table entry is quite large at 40 > bytes (+8): 16 bytes of HASHELEMENT header (of which the last 4 bytes are > padding), 20 bytes of BufferTag, and 4 bytes for the offset into the shared > bu

Re: RFC: Packing the buffer lookup table

2025-02-04 Thread Matthias van de Meent
On Thu, 30 Jan 2025 at 08:48, Matthias van de Meent wrote: > > Together that results in the following prototype patchset. Here's an alternative patch, which replaces dynahash in the buffer lookup table with an open-coded replacement that has fewer indirections during lookups, and allows for a muc

Re: RFC: Packing the buffer lookup table

2025-02-04 Thread Matthias van de Meent
On Fri, 31 Jan 2025 at 18:23, James Hunter wrote: > > On Wed, Jan 29, 2025 at 11:49 PM Matthias van de Meent > wrote: > > > > Hi, > > > > Some time ago I noticed that every buffer table entry is quite large at 40 > > bytes (+8): 16 bytes of HASHELEMENT header (of which the last 4 bytes are > >

Re: RFC: Packing the buffer lookup table

2025-02-04 Thread Matthias van de Meent
On Sat, 1 Feb 2025 at 06:01, Zhang Mingli wrote: > > > > Zhang Mingli > www.hashdata.xyz > On Jan 30, 2025 at 15:49 +0800, Matthias van de Meent < boekewurm+postg...@gmail.com>, wrote: > > Hi, > > Thanks for your insights. > While the buffer tag consumes a relatively small amount of space in the o

Re: RFC: Packing the buffer lookup table

2025-01-31 Thread Zhang Mingli
Zhang Mingli www.hashdata.xyz On Jan 30, 2025 at 15:49 +0800, Matthias van de Meent , wrote: > > Some time ago I noticed that every buffer table entry is quite large at 40 > bytes (+8): 16 bytes of HASHELEMENT header (of which the last 4 bytes are > padding), 20 bytes of BufferTag, and 4 bytes

Re: RFC: Packing the buffer lookup table

2025-01-31 Thread James Hunter
On Wed, Jan 29, 2025 at 11:49 PM Matthias van de Meent wrote: > > Hi, > > Some time ago I noticed that every buffer table entry is quite large at 40 > bytes (+8): 16 bytes of HASHELEMENT header (of which the last 4 bytes are > padding), 20 bytes of BufferTag, and 4 bytes for the offset into the

RFC: Packing the buffer lookup table

2025-01-29 Thread Matthias van de Meent
Hi, Some time ago I noticed that every buffer table entry is quite large at 40 bytes (+8): 16 bytes of HASHELEMENT header (of which the last 4 bytes are padding), 20 bytes of BufferTag, and 4 bytes for the offset into the shared buffers array, with generally 8 more bytes used for the bucket pointe