From: | "k(dot)jamison(at)fujitsu(dot)com" <k(dot)jamison(at)fujitsu(dot)com> |
---|---|
To: | "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | RE: [Patch] Optimize dropping of relation buffers using dlist |
Date: | 2019-11-05 09:58:22 |
Message-ID: | OSBPR01MB3207645FE00E613E38AF4098EF7E0@OSBPR01MB3207.jpnprd01.prod.outlook.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 | Content-Type | Size |
---|---|---|
v2-Optimize-dropping-of-relation-buffers-using-dlist.patch | application/octet-stream | 20.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | rtorre | 2019-11-05 10:09:34 | Re: [Proposal] Arbitrary queries in postgres_fdw |
Previous Message | Etsuro Fujita | 2019-11-05 09:35:54 | Re: [PATCH][DOC] Fix for PREPARE TRANSACTION doc and postgres_fdw message. |