Re: Q: performance on some selects (7.0.2)?

Emils,

There is no index on articles.id (should it not be a primary key?)

Regards,
Grant

Emils Klotins wrote:

> A typical query runs like this:
>
> SELECT a.id,a.title,c.fullpath,c.section FROM articles
> a,articles_groups x,newscategories c WHERE x.articleid=a.id AND
> a.categoryid=c.id AND x.groupid='9590' AND a.status=1 AND
> timestamp(a.publishdate,a.publishtime)<'now'::datetime ORDER
> BY a.createddate desc,a.createdtime desc LIMIT 3
>
> Explain says:
>
> NOTICE:  QUERY PLAN:
>
> Sort  (cost=171.93..171.93 rows=1 width=56)
>   ->  Nested Loop  (cost=0.00..171.92 rows=1 width=56)
>         ->  Nested Loop  (cost=0.00..169.95 rows=1 width=36)
>               ->  Seq Scan on articles_groups x  (cost=0.00..12.10
> rows=1 width=4)
>               ->  Seq Scan on articles a  (cost=0.00..135.55 rows=636
> width=32)
>         ->  Seq Scan on newscategories c  (cost=0.00..1.43 rows=43
> width=20)
>
> EXPLAIN
>
> Now, as I understand the thing that slows everything is the Seq
> scan on articles. I wonder why should it be that the query can't use
> index?
>
> TIA!
> Emils

--
> Poorly planned software requires a genius to write it
> and a hero to use it.

Grant Finnemore BSc(Eng)  (mailto:gaf@ucs.co.za)
Software Engineer         Universal Computer Services
Tel  (+27)(11)712-1366    PO Box 31266 Braamfontein 2017, South Africa
Cell (+27)(82)604-5536    20th Floor, 209 Smit St., Braamfontein
Fax  (+27)(11)339-3421    Johannesburg, South Africa