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'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 think that expanding "NOT IN (...)" into a list of 'AND
log_actionseq != NNNNN' is what postgres query does anyway, so any of
these won't make things worse and any 'AND log_actionseq BETWEEN MMM AND
LLL' mixed in will reduce plan size and complexity.

> I'd like for someone else to "use this patch in anger" before I
> consider adding it into CVS HEAD.

I am quite busy right now, but I'll see if I can find some time tomorrow
to check it out.

Thanks :)

-- 
Hannu Krosing <hannu at skype.net>