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