RE: [Patch] Optimize dropping of relation buffers using dlist - Mailing list pgsql-hackers

From k.jamison@fujitsu.com
Subject RE: [Patch] Optimize dropping of relation buffers using dlist
Date
Msg-id OSBPR01MB3207645FE00E613E38AF4098EF7E0@OSBPR01MB3207.jpnprd01.prod.outlook.com
Whole thread Raw
In response to [Patch] Optimize dropping of relation buffers using dlist  ("k.jamison@fujitsu.com" <k.jamison@fujitsu.com>)
Responses Re: [Patch] Optimize dropping of relation buffers using dlist  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
List pgsql-hackers

Hi,

 

> Another one that I'd need feedback of is the use of new dlist operations

> for this cached buffer list. I did not use in this patch the existing

> Postgres dlist architecture (ilist.h) because I want to save memory space

> as much as possible especially when NBuffers become large. Both dlist_node

> & dlist_head are 16 bytes. OTOH, two int pointers for this patch is 8 bytes.

 

In cb_dlist_combine(), the code block below can impact performance

especially for cases when the doubly linked list is long (IOW, many cached buffers).

              /* Point to the tail of main dlist */

              while (curr_main->next != CACHEDBLOCK_END_OF_LIST)

                            curr_main = cb_dlist_next(curr_main);

 

Attached is an improved version of the previous patch, which adds a pointer

information of the TAIL field in order to speed up the abovementioned operation.

I stored the tail field in the prev pointer of the head entry (maybe not a typical

approach). A more typical one is by adding a tail field (int tail) to CachedBufferEnt,

but I didn’t do that because as I mentioned in previous email I want to avoid

using more memory as much as possible.

The patch worked as intended and passed the tests.

 

Any thoughts?

 

 

Regards,

Kirk Jamison

Attachment

pgsql-hackers by date:

Previous
From: Etsuro Fujita
Date:
Subject: Re: [PATCH][DOC] Fix for PREPARE TRANSACTION doc and postgres_fdw message.
Next
From: rtorre@carto.com
Date:
Subject: Re: [Proposal] Arbitrary queries in postgres_fdw