Alvaro Herrera alvhe...@2ndquadrant.com writes:
Here's the final version. I think this is ready to go in.
I got around to reviewing this today. I'm pretty seriously annoyed at
the definition of dlist_delete: it should *not* require the list header.
The present coding simply throws away one of
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Oops. I mentioned this explicitely somewhere in the discussion. I
assumed you had seen that, and that you would have complained had you
found it objectionable.
Sorry, I've been too busy to pay very much attention to this patch.
I think we
Alvaro Herrera escribió:
Here's the final version. I think this is ready to go in.
Committed.
There are several uses of SHM_QUEUE in the backend code which AFAICS can
be replaced with dlist. If someone's looking for an easy project,
here's one.
--
Álvaro Herrera
On Thursday, October 11, 2012 06:37:59 PM Andres Freund wrote:
On Thursday, October 11, 2012 03:27:17 PM Andres Freund wrote:
On Thursday, October 11, 2012 03:23:12 PM Alvaro Herrera wrote:
Alvaro Herrera escribió:
I also included two new functions in that patch, dlisti_push_head and
Alvaro Herrera escribió:
I also included two new functions in that patch, dlisti_push_head and
dlisti_push_tail. These functions are identical to dlist_push_head and
dlist_push_tail, except that they do not accept non-circular lists.
What this means is that callers that find the
On Thursday, October 11, 2012 03:23:12 PM Alvaro Herrera wrote:
Alvaro Herrera escribió:
I also included two new functions in that patch, dlisti_push_head and
dlisti_push_tail. These functions are identical to dlist_push_head and
dlist_push_tail, except that they do not accept non-circular
On Thursday, October 11, 2012 03:27:17 PM Andres Freund wrote:
On Thursday, October 11, 2012 03:23:12 PM Alvaro Herrera wrote:
Alvaro Herrera escribió:
I also included two new functions in that patch, dlisti_push_head and
dlisti_push_tail. These functions are identical to dlist_push_head
Hi Peter,
On Monday, October 08, 2012 09:43:51 PM Peter Geoghegan wrote:
Pendantry: This should be in alphabetical order:
! OBJS = stringinfo.o ilist.o
Argh. Youve said that before. Somehow I reintroduced it...
I notice that the patch (my revision) produces a whole bunch of
warnings like
On 9/30/12 5:42 PM, Andres Freund wrote:
I thought msvc supported _Static_assert as well, but after a short search it
seems I misremembered and it only supports static_assert from C++11 (which is
plausible, because I've worked on a C++11 project which was ported to windows
). I don't know
Andres Freund and...@2ndquadrant.com writes:
On Sunday, September 30, 2012 10:33:28 PM Tom Lane wrote:
I'm still pretty desperately unhappy with your insistence on circularly
linked dlists. Not only does that make initialization problematic,
but now it's not even consistent with slists.
We
On Monday, October 01, 2012 05:33:01 PM Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On Sunday, September 30, 2012 10:33:28 PM Tom Lane wrote:
I'm still pretty desperately unhappy with your insistence on circularly
linked dlists. Not only does that make initialization
Andres Freund and...@2ndquadrant.com writes:
Patch 0001 contains a assert_compatible_types(a, b) and a
assert_compatible_types_bool(a, b) macro which I found very useful to make it
harder to misuse the api. I think its generally useful and possibly should be
used in more places.
This seems
Andres Freund and...@2ndquadrant.com writes:
Current version is available at branch ilist in:
git://git.postgresql.org/git/users/andresfreund/postgres.git
ssh://g...@git.postgresql.org/users/andresfreund/postgres.git
I'm still pretty desperately unhappy with your insistence on circularly
On Sunday, September 30, 2012 06:57:32 PM Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
Patch 0001 contains a assert_compatible_types(a, b) and a
assert_compatible_types_bool(a, b) macro which I found very useful to
make it harder to misuse the api. I think its generally
Andres Freund and...@2ndquadrant.com writes:
Perhaps we need to decouple _Static_assert support from compound statement
support at some point, but we will see.
Yeah, possibly, but until we have an example of a non-gcc-compatible
compiler that can do something equivalent, it's hard to guess how
Hi,
On Sunday, September 30, 2012 10:33:28 PM Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
Current version is available at branch ilist in:
git://git.postgresql.org/git/users/andresfreund/postgres.git
ssh://g...@git.postgresql.org/users/andresfreund/postgres.git
I'm
On Sunday, September 30, 2012 10:48:01 PM Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
Perhaps we need to decouple _Static_assert support from compound
statement support at some point, but we will see.
Yeah, possibly, but until we have an example of a non-gcc-compatible
On Friday, September 14, 2012 10:57:54 PM Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
One thing I would like more input in, is whether people think it's
worthwhile to split dlists and slists into separate files. Thus far
this has been mentioned by three people
Andres Freund and...@2ndquadrant.com writes:
The reason I had the header declare DEFINE_ILIST_FUNCTIONS (or rather
ILIST_USE_DEFINITION back then) instead of reusing USE_INLINE directly is
that
it makes it easier to locally change a module to not inlining which makes
testing the
On Saturday, September 29, 2012 01:39:03 AM Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
The reason I had the header declare DEFINE_ILIST_FUNCTIONS (or rather
ILIST_USE_DEFINITION back then) instead of reusing USE_INLINE directly is
that it makes it easier to locally change
Andres Freund and...@2ndquadrant.com writes:
On Saturday, September 29, 2012 01:39:03 AM Tom Lane wrote:
Right offhand it doesn't seem like it really gains that much even for
that use-case. You'd end up editing the include file either way, just
slightly differently.
Well, with USE_INLINE
On Saturday, September 29, 2012 01:54:37 AM Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On Saturday, September 29, 2012 01:39:03 AM Tom Lane wrote:
Right offhand it doesn't seem like it really gains that much even for
that use-case. You'd end up editing the include file
Add [ds]list's which can be used to embed lists in bigger data structures
without additional memory management
Alvaro, Andres, Review by Peter G. and Tom
This is missing Robert. Sorry for that.
Andres
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL
On Saturday, September 15, 2012 07:21:44 PM Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On Saturday, September 15, 2012 07:32:45 AM Tom Lane wrote:
Well, actually, that just brings us to the main point which is: I do not
believe that circular links are a good design choice
Hi,
On Sunday, September 16, 2012 04:23:14 PM Andres Freund wrote:
What do you think about something like:
typedef struct dlist_iter
{
/*
* Use a union with equivalent storage as dlist_node to make it possible
to * initialize the struct inside a macro without multiple
Hi Tom,
On Saturday, September 15, 2012 07:32:45 AM Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On Friday, September 14, 2012 10:48:35 PM Tom Lane wrote:
Instead let's provide a macro for an empty list value, so that you can
do something like
static ilist_d_head
Andres Freund and...@2ndquadrant.com writes:
On Saturday, September 15, 2012 07:32:45 AM Tom Lane wrote:
Well, actually, that just brings us to the main point which is: I do not
believe that circular links are a good design choice here.
I think I have talked about the reasoning on the list
Excerpts from Alvaro Herrera's message of vie sep 14 14:22:18 -0300 2012:
Here's an updated version of both patches, as well as a third patch that
converts the cc_node list link in catcache.c into an slist.
One thing I would like more input in, is whether people think it's
worthwhile to split
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Here's an updated version of both patches, as well as a third patch that
converts the cc_node list link in catcache.c into an slist.
There's a lot of stuff here that seems rather unfortunate and/or sloppy.
Does it even compile? The 0002 patch
Alvaro Herrera alvhe...@2ndquadrant.com writes:
One thing I would like more input in, is whether people think it's
worthwhile to split dlists and slists into separate files. Thus far
this has been mentioned by three people independently.
They're small enough and similar enough that one header
Excerpts from Tom Lane's message of vie sep 14 17:48:35 -0300 2012:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Here's an updated version of both patches, as well as a third patch that
converts the cc_node list link in catcache.c into an slist.
There's a lot of stuff here that seems
Hi,
On Friday, September 14, 2012 10:48:35 PM Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Here's an updated version of both patches, as well as a third patch that
converts the cc_node list link in catcache.c into an slist.
There's a lot of stuff here that seems rather
Andres Freund and...@2ndquadrant.com writes:
On Friday, September 14, 2012 10:48:35 PM Tom Lane wrote:
Instead let's provide a macro for an empty list value, so that you can
do something like
static ilist_d_head DatabaseList = EMPTY_DLIST;
I don't think that can work with dlists because they
Hi Alvaro,
Thanks for the review!
On Thursday, September 06, 2012 06:09:35 PM Alvaro Herrera wrote:
Here's a prettified version of this stuff. I found one bug in the macro
ilist_s_head: the test was reversed.
Oh, good catch. I had only used the _unchecked version because my code checked
that
Here's a prettified version of this stuff. I found one bug in the macro
ilist_s_head: the test was reversed. Also, curiously, the macro had the
same name as the struct, so I renamed the macro. I take it you haven't
used this macro, so maybe it shouldn't be there at all? Or maybe I
completely
On Thu, Sep 6, 2012 at 12:09 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Here's a prettified version of this stuff. I found one bug in the macro
ilist_s_head: the test was reversed. Also, curiously, the macro had the
same name as the struct, so I renamed the macro. I take it you
Excerpts from Andres Freund's message of jue jun 28 17:06:49 -0400 2012:
On Thursday, June 28, 2012 10:03:26 PM Andres Freund wrote:
What I wonder is how hard it would be to remove catcache.h's structs into
the implementation. Thats the reason why the old and new list
implementation
On 5 July 2012 02:49, Peter Geoghegan pe...@2ndquadrant.com wrote:
On 28 June 2012 19:20, Andres Freund and...@2ndquadrant.com wrote:
0001-Add-embedded-list-interface.patch
Looks good now?
I have a few gripes.
We are passed the nominal deadline. Had you planned on getting back to
me this
On Monday, July 23, 2012 12:55:01 PM Peter Geoghegan wrote:
On 5 July 2012 02:49, Peter Geoghegan pe...@2ndquadrant.com wrote:
On 28 June 2012 19:20, Andres Freund and...@2ndquadrant.com wrote:
0001-Add-embedded-list-interface.patch
Looks good now?
I have a few gripes.
We are
On 28 June 2012 19:20, Andres Freund and...@2ndquadrant.com wrote:
0001-Add-embedded-list-interface.patch
Looks good now?
I have a few gripes.
+ * there isn't much we can test in a single linked list except that its
There are numerous references to single linked lists, where, I
believe,
On Tue, Jun 26, 2012 at 7:26 PM, Andres Freund and...@2ndquadrant.com wrote:
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
This code doesn't follow PostgreSQL coding
On Thursday, June 28, 2012 06:23:05 PM Robert Haas wrote:
On Tue, Jun 26, 2012 at 7:26 PM, Andres Freund and...@2ndquadrant.com
wrote:
Attached are three patches:
1. embedded list implementation
2. make the list implementation usable without USE_INLINE
3. convert all callers to ilist.h
Excerpts from Andres Freund's message of jue jun 28 14:20:59 -0400 2012:
Looks good now?
The one thing I dislike about this code is the names you've chosen. I
mean, ilist_s_stuff and ilist_d_stuff. I mean, why not just Slist_foo
and Dlist_bar, say? As far as I can tell, you've chosen the i
On Thu, Jun 28, 2012 at 3:47 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Andres Freund's message of jue jun 28 14:20:59 -0400 2012:
Looks good now?
The one thing I dislike about this code is the names you've chosen. I
mean, ilist_s_stuff and ilist_d_stuff. I mean,
On Thursday, June 28, 2012 09:47:05 PM Alvaro Herrera wrote:
Excerpts from Andres Freund's message of jue jun 28 14:20:59 -0400 2012:
Looks good now?
The one thing I dislike about this code is the names you've chosen. I
mean, ilist_s_stuff and ilist_d_stuff. I mean, why not just Slist_foo
On Thursday, June 28, 2012 10:03:26 PM Andres Freund wrote:
What I wonder is how hard it would be to remove catcache.h's structs into
the implementation. Thats the reason why the old and new list
implementation currently is included all over the backend...
Moving them into the implementation
Excerpts from Andres Freund's message of jue jun 28 16:03:26 -0400 2012:
On Thursday, June 28, 2012 09:47:05 PM Alvaro Herrera wrote:
Excerpts from Andres Freund's message of jue jun 28 14:20:59 -0400 2012:
Looks good now?
The one thing I dislike about this code is the names you've
Excerpts from Andres Freund's message of jue jun 28 17:06:49 -0400 2012:
On Thursday, June 28, 2012 10:03:26 PM Andres Freund wrote:
What I wonder is how hard it would be to remove catcache.h's structs into
the implementation. Thats the reason why the old and new list
implementation
On Thursday, June 28, 2012 11:45:08 PM Alvaro Herrera wrote:
Excerpts from Andres Freund's message of jue jun 28 17:06:49 -0400 2012:
On Thursday, June 28, 2012 10:03:26 PM Andres Freund wrote:
What I wonder is how hard it would be to remove catcache.h's structs
into the implementation.
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
50 matches
Mail list logo
