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(at)ucs(dot)co(dot)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