On T, 2005-08-09 at 17:07 -0400, Christopher Browne wrote:

> I'm not sure a temp table will work, based on where the actionseq values
> come from :-(.

If the usual case is also a continuous list of integers, I see no real
need for making it more complex. It would have been the last effort if
the integers had been sparse but still plenty;

> Alas, the problem is that elegant Pythonic answers aren't much good for
> helping with code in C, as C hasn't got the string parsing capabilities,
> and allocating memory dynamically requires a fair bit of work "by hand."

I _tried_ to write as C-like (and not really elegant :) ) code as
possible, so that it would be useful for actual C coding - there are
only 4 variables ( n, n1, range_start, range_end ), the list is scanned
once and the actual query parts can be added also continuously when
ready.

And I guess that these integers come from some previous query, so they
are also kind of "pre-allocated".

> I've got a FSM whiteboarded that will efficiently parse the list of
> integers (when you can use an FSM, your problem has "blazingly fast"
> written all over it!); I'll have to do a bit of thinking about what to
> do about processing those integers :-).
> 
> I now know the FSM part is easy; I'll have to sleep on the rest...

my python code was just for testing the processing algorithm (I got it
work right in 4 tries :)

...

> >what does "log_actionseq not in (..." exactly check for ?
> >  
> >
> It's excluding entries that aren't in the present SYNCs being processed.
> 
> I wouldn't be surprised if you'd get better result by either:
> 
> a) Forcing the slon to do one sync at a time ---> -g 1

I tried that (but only after the damage was done).

> b) Forcing the slon to do a whole lot of syncs at a time --> -g 1000

Usually I run with -g 100

-- 
Hannu Krosing <hannu at skype.net>