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

I have the following tables:
******************        Table "articles" Attribute  |  Type   | Modifier
-------------+---------+----------id          | integer |title       | text    |authorid    | integer |sourceid    |
integer|createddate | date    |createdtime | time    |publishdate | date    |publishtime | time    |categoryid  |
integer|groupid     | integer |lead        | text    |body        | text    |status      | integer |typeid      |
integer|hot         | integer |parentid    | integer |
 
Indices: articles_categoryid,        articles_createddate,        articles_createdtime,        articles_groupid,
articles_hot,       articles_publish_datetime,        articles_sourceid,        articles_status,
articles_typeid
--
Table "articles_groups"Attribute |  Type   | Modifier
-----------+---------+----------articleid | integer | not nullgroupid   | integer | not null
---              Table "newscategories"  Attribute   |     Type     |       Modifier
---------------+--------------+----------------------id            | integer      | not nullparentid      | integer
| not null default '0'name          | varchar(255) | not null default ''directoryname | varchar(255) | not null default
''metakeywords | text         |status        | integer      | not null default 1sortnr        | integer      | not null
default0level         | integer      | not null default 1fullpath      | text         |section       | integer      |
 
Index: newscategories_pkey
*********************

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.95rows=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

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

"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