Re: Select very slow

>
> That 'count(*)' is going to be slow.
> Try counting a column that's indexed (p.doc might work?)

That is not the case, you can convince yourself with explain - you get the
same plan(s) :

e.g : ( table dim0 with indexed column d0key ) ...

explain select count(*) from dim0 where d0key < 1000;

Aggregate (cost=96.13..96.13 rows=1 width=0)
-> Index Scan using dim0_pk on dim0 (cost=0.00..93.63 rows=1000 width=0)

explain select count(d0key) from dim0 where d0key < 1000;

Aggregate (cost=96.13..96.13 rows=1 width=4)
-> Index Scan using dim0_pk on dim0 (cost=0.00..93.63 rows=1000 width=4)

> (the tables and query snipped..).
> anyone help-me ?
>

I would try to make the primary key ( doc) a fixed length varchar(n) instead
of text if possible, as text is intended for very long strings and btree
indexes usually perform best on (small) fixed length columns.

If your key is going to be a really long string then maybe rethink the design
( use a "synthetic" key like a sequence or integer checksum of doc to index
on ).

perform a vacuum analyze and then post the output of the explain below to
this list !

explain select p.city,count(*) from sales s, person p where s.doc = p.doc
group by p.city;

Cheers

Mark