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

"Emils Klotins" <emils@grafton.lv> writes:
> 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)

Given the small estimated costs and row counts, I wonder whether you've
ever vacuumed articles_groups and newscategories.  The plan is not too
unreasonable if the planner is right about how many rows will be matched
in each of those tables --- but if you've never done a vacuum then the
planner has no accurate stats to work with, so its guesses are likely
way off.

The plan is clearly handicapped by the lack of indexes on article.id
and articles_groups.groupid, also.  You seem to have indexes on all
the wrong columns of articles :-( ... each of those indexes costs you
on updates, but will it ever be useful in a query?
        regards, tom lane