very slow response time on large, multi-table view - Mailing list pgsql-general

From Charles Hornberger
Subject very slow response time on large, multi-table view
Date
Msg-id 3.0.5.32.19990111165844.00a765c0@tabloid.net
Whole thread Raw
List pgsql-general
Could anyone help me figure out why SELECTing data from a pretty complex
view is happening incredibly slowly on Postgres?  I'm porting a database
from Solid to Postgres, and had to rewrite the following view from Solid:

  CREATE VIEW FRONT_VIEW AS
    SELECT A.ARTICLE_ID, S.SUBJECT, A.HEADLINE, A.SUBHEAD, A.BYLINE,
      A.COUNTRY_ID, A.PUBL_DATE,
      A.ARTICLE_TEXT,
      AC.ART_SRC_DISPLAY, AT.ARTICLE_TYPE, D.DATELINE, F.PRIORITY
    FROM FRONTPAGE F, ARTICLES A, SUBJECTS S, ARTICLE_TYPES AT, DATELINE D
      LEFT JOIN ARTICLES A ON F.ARTICLE_ID = A.ARTICLE_ID
      LEFT JOIN ARTICLE_SOURCES AC ON A.ART_SRC_ID = AC.ART_SRC_ID
      LEFT JOIN ARTICLE_TYPES AT ON A.ART_TYPE_ID = AT.ART_TYPE_ID
      LEFT JOIN DATELINES D ON A.DATELINE_ID = D.DATELINE_ID
      LEFT JOIN SUBJECTS S ON A.SUBJECT1_ID = S.SUBJECT_ID;

I rewrote it like so under Postgres:

 CREATE VIEW FRONT_VIEW AS
   SELECT
     A.ARTICLE_ID, A.HEADLINE, A.SUBHEAD, A.BYLINE, A.COUNTRY_ID,
A.PUBL_DATE, A.ARTICLE_TEXT,
     AC.ART_SRC_DISPLAY, AT.ARTICLE_TYPE, D.DATELINE,
     F.PRIORITY
   FROM
     FRONTPAGE F, ARTICLES A, ARTICLE_SOURCES AC, ARTICLE_TYPES AT,
DATELINES D, SUBJECTS S
   WHERE F.ARTICLE_ID = A.ARTICLE_ID         -- both are indexed
     AND AC.ART_SRC_ID = A.ART_SRC_ID        -- ac.art_src_id is indexed
     AND AT.ART_TYPE_ID = A.ART_TYPE_ID      -- at.art_type_id is indexed
     AND D.DATELINE_ID = A.DATELINE_ID       -- both are indexed
     AND S.SUBJECT_ID = A.SUBJECT1_ID;      -- s.subject_id is indexed


I was surprised to see that when doing a SELECT * FROM FRONT_VIEW; in psql,
the database took nearly 15 seconds to execute the query.  I vacuumed the
DB (although there's almost nothing in it), and tried again -- but got the
same result.  Running the same query in the Solid sql monitor produced an
almost instantaneous response.

Finally, I did an "explain" on the query.  But I have to confess I don't
know how to interpret the output:

apx2=> explain select * from front_view;
NOTICE:  QUERY PLAN:

Nested Loop  (cost=10.36 size=2 width=116)
  ->  Nested Loop  (cost=8.30 size=2 width=114)
        ->  Nested Loop  (cost=6.23 size=2 width=100)
              ->  Nested Loop  (cost=4.16 size=2 width=86)
                    ->  Nested Loop  (cost=2.10 size=2 width=72)
                          ->  Seq Scan on frontpage f  (cost=1.03 size=1
width=6)
                          ->  Seq Scan on articles a  (cost=1.07 size=2
width=66)
                    ->  Seq Scan on datelines d  (cost=1.03 size=1 width=14)
              ->  Seq Scan on article_sources ac  (cost=1.03 size=1 width=14)
        ->  Seq Scan on article_types at  (cost=1.03 size=1 width=14)
  ->  Seq Scan on subjects s  (cost=1.03 size=1 width=2)

EXPLAIN

Solid's "explain" tool generated the following output:

explain plan for select * from front_view;
       ID   UNIT_ID    PAR_ID JOIN_PATH UNIT_TYPE          INFO
       --   -------    ------ --------- ---------          ----
        1         1         0         2 JOIN UNIT
        2         2         1         3 JOIN UNIT          LOOP JOIN
        3         2         1        12
        4         3         2         4 JOIN UNIT          LOOP JOIN
        5         3         2        11
        6         4         3         5 JOIN UNIT          LOOP JOIN
        7         4         3        10
        8         5         4         6 JOIN UNIT          LOOP JOIN
        9         5         4         9
       10         6         5         7 JOIN UNIT          LOOP JOIN
       11         6         5         8
       12         7         6         0 TABLE UNIT         FRONTPAGE
       13         7         6         0                    SCAN TABLE
       14         8         6         0 TABLE UNIT         ARTICLES
       15         8         6         0                    PRIMARY KEY
       16         8         6         0                    ARTICLE_ID = ...
       17         9         5         0 TABLE UNIT         ARTICLE_SOURCES
       18         9         5         0                    PRIMARY KEY
       19         9         5         0                    ART_SRC_ID = ...
       20        10         4         0 TABLE UNIT         ARTICLE_TYPES
       21        10         4         0                    PRIMARY KEY
       22        10         4         0                    ART_TYPE_ID = ...
       23        11         3         0 TABLE UNIT         CITY_DATELINES
       24        11         3         0                    PRIMARY KEY
       25        11         3         0                    CITY_DATELINE_ID
= ...
       26        12         2         0 TABLE UNIT         SUBJECTS
       27        12         2         0                    PRIMARY KEY
       28        12         2         0                    SUBJECT_ID = ...
28 rows fetched.


I'm running Postgres 6.4 on Linux 2.0.35 on a Pentium 133 with a bunch of
RAM (I think it's 192MB).

Thanks in advance for any advice.

Charlie


pgsql-general by date:

Previous
From: Jixue Jerry Liu
Date:
Subject: two questions
Next
From: "Paolo P. Lo Giacco"
Date:
Subject: Postgres+ODBC+BDE+Delphi