embedded list v2
Andres Freund <andres@2ndquadrant.com>
From: Andres Freund <andres@2ndquadrant.com>
To: pgsql-hackers@postgresql.org
Cc: Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@postgresql.org>, Peter Geoghegan <peter@2ndquadrant.com>
Date: 2012-06-26T23:26:00Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Provide some static-assertion functionality on all compilers.
- 0d0aa5d29175 9.3.0 cited
-
Add infrastructure for compile-time assertions about variable types.
- ea473fb2dee7 9.3.0 cited
-
Remove 576 references of include files that were not needed.
- e0522505bd13 8.2.0 cited
-
More include file adjustments.
- b43ebe5f83b2 8.2.0 cited
-
Allow each C include file to compile on its own by including any needed
- b85a965f5fc7 8.2.0 cited
Attachments
- 0001-Add-embedded-list-interface-header-only.patch (text/x-patch) patch 0001
- 0002-Rework-the-newly-added-ilist-interface-to-be-usable-.patch (text/x-patch) patch 0002
- 0003-Remove-usage-of-lib-dllist.h-and-replace-it-by-the-n.patch (text/x-patch) patch 0003
Hi, To recapitulate why I think this sort of embedded list is worthwile: * minimal memory overhead (16 bytes for double linked list heads/nodes on 64bit systems) * no additional memory allocation overhead * no additional dereference to access the contents of a list element * most modifications are completely branchless * the current dllist.h interface has double the memory overhead and much more complex manipulation operators * Multiple places in postgres have grown local single or double linked list implementations * I need it ;) Attached are three patches: 1. embedded list implementation 2. make the list implementation usable without USE_INLINE 3. convert all callers to ilist.h away from dllist.h For 1 I: a. added more comments and some introduction, some more functions b. moved the file from utils/ilist.h to lib/ilist.h c. actually included the c file with the check functions d. did *not* split it up into single/double linked list files, doesn't seem to be worth the trouble given how small ilist.(c|h) are e. did *not* try to get an interface similar to dllist.h. I don't think the old one is better and it makes the breakage more obvious should somebody else use the old implementation although I doubt it. I can be convinced to do d. and e. but I don't think they are an improvement. For 2 I used ugly macro hackery to avoid declaring every function twice, in a c file and in a header. Opinions on the state of the above patches? I did not expect any performance difference in the current usage, but just to be sure I ran the following tests: connection heavy: pgbench -n -S -p 5501 -h /tmp -U andres postgres -c 16 -j 16 -T 10 -C master: 3109 3024 3012 ilist: 3097 3033 3024 somewhat SearchCatCache heavy: pgbench -n -S -p 5501 -h /tmp -U andres postgres -T 100 -c 16 -j 1 master: 98979.453879 99554.485631 99393.587880 ilist: 98960.545559 99583.319870 99498.923273 As expected the differences are on the level of noise... Greetings, Andres -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services