On E, 2005-09-05 at 19:22 -0400, Christopher Browne wrote:
> Michael Crozier <crozierm at conducivetech.com> writes:
> 
> >> >> I guess that in my case the improvement was more like 95%.
> >> >
> >> > I also saw a significant increase.  The difference between my "fast"
> >> > machine and "slow" machine seemed to indicate that the difference was
> >> > primarily CPU related.
> >>
> >> That's consistent with it using a seq scan and having to sort the table.
> >
> > It was performing indexed lookups for both versions of the query.  EXPLAIN 
> > showed that the only difference was the tableid filter(s). It sounds odd, but 
> > I'm fairly confident thats what I was seeing.  Unfortunately I didn't keep 
> > notes and can't be completely certain.

Original query (without index on XID column) did the most inefficient
thing possible - an index scan over all rows, doing index qual on
constant first column .

> > The index and static group size were definitely the big improvment, though.
> 
> I think I missaid part of that.
> 
> It still needs to do a sort in order to put things in order of the
> "action sequence".  That will be an in-memory (in the PG backend)
> sort.

Any idea why we have "action sequence" in the default index at all ? It
seems that it can't ever be used ?

-- 
Hannu Krosing <hannu at skype.net>