On K, 2005-08-10 at 17:39 -0400, Christopher Browne wrote:
> Hannu Krosing <hannu at skype.net> writes:
> > 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 :)
> >
> > ...
> 
> I have a patch that passes the "test_1_pgbench" test, which definitely
> exercises it.  (Albeit not with Just Insanely Big Queries...)
> 
> If the set of "actionseq" values are being returned in random order,
> it won't turn out terribly well, but if they are in even a fairly
> approximate ordering, it'll be a BIG help.  And it looks as though
> they are returned more or less in order.
> 
> I'd like for someone else to "use this patch in anger" before I
> consider adding it into CVS HEAD.
> 
> In particular, can Jan comment on how sl_setsync gets populated?  Do I
> get to assume a reasonably strong ordering of the elements embedded in
> sl_setsync.ssy_action_list?
> 

I found myself again in a situation wher I had to test your patch :)

as all my 650K ids were consecutive it produced a subclause ending in
"and ( )" and thus a ayntax error.

I digged a little, and found out that it was missing the final (after
the loop) part.

so this part of 

> +			state = BETWEEN_NUMBERS;
> +			curr_number = 0;
> +		}
> +		ssy_actionlist++;
> +	}


should be expanded to this to produce results and not leave out the last
range. (which in my case was the *whole* range :) )

            state = BETWEEN_NUMBERS;
            curr_number = 0;
        }
        ssy_actionlist++;
    }
    /* process last range, if it exists */
    if ( curr_min || curr_max) {
        if (first_subquery) {
            first_subquery = 0;
        } else {
            slon_appendquery(action_subquery, " and ");
        }
        if (curr_max == curr_min) {
            slon_log(SLON_DEBUG1, "simple entry - %d\n", curr_max);
            slon_appendquery(action_subquery,
                     " log_actionseq <> '%d' ", curr_max);
        } else {
            slon_log(SLON_DEBUG1, "between entry - %d %d\n",
                 curr_min, curr_max);
            slon_appendquery(action_subquery,
                     " log_actionseq not between '%d' and '%d' ",
                     curr_min, curr_max);
        }


-- 
Hannu Krosing <hannu at skype.net>