Re: [HACKERS] ilist.h is not useful as-is

2013-07-24 Thread Tom Lane
Andres Freund writes: > The first attached patch adds slist_delete_current(), updates the > comments addressing your points and converts the bgworker code to pass > the iterator around (it's more efficient which might actually matter > with a few hundred bgworkers). Applied with fixes. The slist

Re: [HACKERS] ilist.h is not useful as-is

2013-07-24 Thread Andres Freund
> Andres Freund writes: > > The first attached patch adds slist_delete_current(), updates the > > comments addressing your points and converts the bgworker code to pass > > the iterator around (it's more efficient which might actually matter > > with a few hundred bgworkers). > > I found the added

Re: [HACKERS] ilist.h is not useful as-is

2013-07-24 Thread Tom Lane
Andres Freund writes: > The first attached patch adds slist_delete_current(), updates the > comments addressing your points and converts the bgworker code to pass > the iterator around (it's more efficient which might actually matter > with a few hundred bgworkers). > I found the added newlines in

Re: [HACKERS] ilist.h is not useful as-is

2013-07-24 Thread Andres Freund
Hi, On 2013-07-24 11:49:20 -0400, Tom Lane wrote: > Andres Freund writes: > > This will require another member variable in slist_mutable_iter which > > obviously will need to be maintained, but that seems fine to me since it > > will reduce the cost of actually deleting noticeably. > > I think t

Re: [HACKERS] ilist.h is not useful as-is

2013-07-24 Thread Alvaro Herrera
Andres Freund wrote: > On 2013-07-24 11:53:39 -0400, Alvaro Herrera wrote: > > Andres Freund wrote: > > Amusingly, this will mean ForgetBackgroundWorker() will need to have a > > slist_mutable_iter * argument if it wants to use the new function ... > > The only alternative I see would be to pass

Re: [HACKERS] ilist.h is not useful as-is

2013-07-24 Thread Andres Freund
On 2013-07-24 11:53:39 -0400, Alvaro Herrera wrote: > Andres Freund wrote: > > On 2013-07-24 11:26:00 -0400, Tom Lane wrote: > > > > So I'm going to end up hand-implementing the same kind of manipulation > > > we frequently use with traditional Lists, namely keep a second variable > > > that's the

Re: [HACKERS] ilist.h is not useful as-is

2013-07-24 Thread Alvaro Herrera
Andres Freund wrote: > On 2013-07-24 11:26:00 -0400, Tom Lane wrote: > > So I'm going to end up hand-implementing the same kind of manipulation > > we frequently use with traditional Lists, namely keep a second variable > > that's the preceding list element (not the next one) so I can unlink and >

Re: [HACKERS] ilist.h is not useful as-is

2013-07-24 Thread Tom Lane
Andres Freund writes: > On 2013-07-24 11:26:00 -0400, Tom Lane wrote: >> So I'm going to end up hand-implementing the same kind of manipulation >> we frequently use with traditional Lists, namely keep a second variable >> that's the preceding list element (not the next one) so I can unlink and >>

Re: [HACKERS] ilist.h is not useful as-is

2013-07-24 Thread Andres Freund
On 2013-07-24 11:26:00 -0400, Tom Lane wrote: > So I went off to implement the SPITupleTable tracking discussed in > <6553.1374424...@sss.pgh.pa.us>, and thought it would be cool to > use the slist infrastructure defined in lib/ilist.h rather than > creating a separate List node for each SPITupleTa

[HACKERS] ilist.h is not useful as-is

2013-07-24 Thread Tom Lane
So I went off to implement the SPITupleTable tracking discussed in <6553.1374424...@sss.pgh.pa.us>, and thought it would be cool to use the slist infrastructure defined in lib/ilist.h rather than creating a separate List node for each SPITupleTable struct. However, I soon ran into a problem: there'