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
32 matches
Mail list logo
