Alvaro Herrera 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 should remove the head
Tom Lane escribió:
> Alvaro Herrera 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
Alvaro Herrera 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 the primary advantages o
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 Herrerahttp://www.2n
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_hea
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_p
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-ci
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 non-circu
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 li
On Monday, October 01, 2012 05:33:01 PM Tom Lane wrote:
> Andres Freund 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,
> >> bu
Andres Freund 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 literally have t
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 kno
On Sunday, September 30, 2012 10:48:01 PM Tom Lane wrote:
> Andres Freund 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
Hi,
On Sunday, September 30, 2012 10:33:28 PM Tom Lane wrote:
> Andres Freund 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 despe
Andres Freund 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 we
might need to alt
On Sunday, September 30, 2012 06:57:32 PM Tom Lane wrote:
> Andres Freund 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
> > possi
Andres Freund 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
linked dlists. Not only
Andres Freund 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 like basically a goo
> 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 Develop
On Saturday, September 29, 2012 01:54:37 AM Tom Lane wrote:
> Andres Freund 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
Andres Freund 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 you have to recom
On Saturday, September 29, 2012 01:39:03 AM Tom Lane wrote:
> Andres Freund 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 no
Andres Freund 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 !USE_INLINE case easier.
On Friday, September 14, 2012 10:57:54 PM Tom Lane wrote:
> Alvaro Herrera 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
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 e
On Saturday, September 15, 2012 07:21:44 PM Tom Lane wrote:
> Andres Freund 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.
> >
> >
Andres Freund 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 before, but here it
Hi Tom,
On Saturday, September 15, 2012 07:32:45 AM Tom Lane wrote:
> Andres Freund 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 = EMPT
Andres Freund 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 are circular a
Hi,
On Friday, September 14, 2012 10:48:35 PM Tom Lane wrote:
> Alvaro Herrera 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
Excerpts from Tom Lane's message of vie sep 14 17:48:35 -0300 2012:
> Alvaro Herrera 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 a
Alvaro Herrera 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 and one .c file
seem
Alvaro Herrera 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 refers to a typedef ilist
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 spl
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
tha
On Thu, Sep 6, 2012 at 12:09 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. 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,
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 mi
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 Monday, July 23, 2012 12:55:01 PM Peter Geoghegan wrote:
> On 5 July 2012 02:49, Peter Geoghegan wrote:
> > On 28 June 2012 19:20, Andres Freund wrote:
> >> <0001-Add-embedded-list-interface.patch>
> >>
> >> Looks good now?
> >
> > I have a few gripes.
>
> We are passed the nominal deadline
On 5 July 2012 02:49, Peter Geoghegan wrote:
> On 28 June 2012 19:20, Andres Freund 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 commitfest? If not, I'll shelve my
On 28 June 2012 19:20, Andres Freund 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, "singly linked
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 implemen
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
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 name
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
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 Slis
On Thu, Jun 28, 2012 at 3:47 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_f
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 Thursday, June 28, 2012 06:23:05 PM Robert Haas wrote:
> On Tue, Jun 26, 2012 at 7:26 PM, Andres Freund
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 dllis
On Tue, Jun 26, 2012 at 7:26 PM, Andres Freund 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 style guidelines; in
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 ar
51 matches
Mail list logo
