Re: won't drop the view

Josh,
I just recreated all the indexes on the tables, but it didn't help.
Please let me know if there is any other information you need to help me
resolve performance issue.
Here are answers to your questions:

1. I am using PostgreSQL 7.1.2
2. Linux RedHat 7.1
3. Pentium II 400 with 256 Megs of RAM   14 out of 17 Gigs are free (there is only one disk on this system)
4. Here is the view definition:
CREATE VIEW progress_report AS
SELECT  acts.product_code AS product_code,       acts.component AS component,       acts.priority AS priority,
acts.statusAS status,       COALESCE(media_acts.art_checked_in, 0) AS art_in,       COALESCE(media_acts.art_waiting, 0)
ASart_wait,       COALESCE(media_acts.audio_checked_in, 0) AS audio_in,       COALESCE(media_acts.audio_waiting, 0) AS
audio_wait,      COALESCE(media_acts.video_checked_in, 0) AS video_in,       COALESCE(media_acts.video_waiting, 0) AS
video_wait
FROM       (SELECT objectid AS actid,               productcode AS product_code,               actname AS component,
          status AS status,               priority AS priority       FROM activity       WHERE   activity.productcode ~
'^m3')acts
 

LEFT OUTER JOIN       (       SELECT  actid,               SUM     (CASE WHEN
lower(stats.media_status)~'^checked'                                       AND lower(stats.type)='art'
    THEN 1 ELSE 0 END)               AS art_checked_in,               SUM     (CASE WHEN
 
lower(stats.media_status)~'^waiting'                                       AND lower(stats.type)='art'
    THEN 1 ELSE 0 END)               AS art_waiting,               SUM     (CASE WHEN
 
lower(stats.media_status)~'^checked'                                       AND lower(stats.type)='audio'
      THEN 1 ELSE 0 END)               AS audio_checked_in,               SUM     (CASE WHEN
 
lower(stats.media_status)~'^waiting'                                       AND lower(stats.type)='audio'
      THEN 1 ELSE 0 END)               AS audio_waiting,               SUM     (CASE WHEN
 
lower(stats.media_status)~'^checked'                                       AND lower(stats.type)='video'
      THEN 1 ELSE 0 END)               AS video_checked_in,               SUM     (CASE WHEN
 
lower(stats.media_status)~'^waiting'                                       AND lower(stats.type)='video'
      THEN 1 ELSE 0 END)               AS video_waiting       FROM       (       (SELECT media.objectid AS mediaid,
         media.status AS media_status,               mediatypemap.typecategory AS type,               media.activity AS
actid      FROM media, mediatypemap       WHERE media.mediatype = mediatypemap.mediatype)               UNION
(SELECTintsetmedia.media AS mediaid,               media.status AS media_status,
mediatypemap.typecategoryAS type,               set.activity AS actid       FROM    intsetmedia, set, media,
mediatypemap      WHERE   media.mediatype = mediatypemap.mediatype               AND intsetmedia.set = set.objectid
         AND intsetmedia.media = media.objectid       )               UNION       (SELECT dtrowmedia.media AS mediaid,
            media.status AS media_status,               mediatypemap.typecategory AS type,
datatable.activityAS actid       FROM media, mediatypemap, dtrowmedia, dtrow, dtcol, datatable       WHERE
media.mediatype= mediatypemap.mediatype               AND dtrowmedia.media = media.objectid               AND
dtrowmedia.dtrow= dtrow.objectid               AND dtrow.dtcol = dtcol.objectid               AND dtcol.datatable =
datatable.objectid
       )       ) stats       GROUP BY actid ) media_acts

ON       acts.actid = media_acts.actid
ORDER BY product_code;


5. None of the tables involved in the view has BLOBs in it.   Row count for the tables are as follows:   activity:
253  media:    12406   set:         826   intsetmedia:    22916   mediatypemap: 25   datatable:    318   dtcol:
1698  dtrow:      18406   dtrowmedia: 10238
 

6. I didn't have debug on when running vacuum, so I can't tell you if it
raised any errors.


thanks,





Josh Berkus wrote:

> Oleg,
>
> > I just vacuumed and vacuumed analyzed my database. Now, I am trying
> > to
> > execute a view, which was perfectly working before, but it seems to
> > be
> > very slow. It was sitting there for 10 mins before I cancelled it.
> > Usually it was taking on the order of 5 secs to execute the view.
> > I just recreated the view, but the problem still persists.
> > Here is what EXPLAIN tells me:
> > EXPLAIN select * from progress_report;
> > Subquery Scan progress_report  (cost=16386.56..16386.56 rows=2
> > width=128)
> >   ->  Sort  (cost=16386.56..16386.56 rows=2 width=128)
> >         ->  Nested Loop  (cost=16299.45..16386.55 rows=2 width=128)
> >
> > How can I "restore" the "before-the-vacuum" performance?
> > thanks,
>
> This is not normal.  I suspect that you have something wrong with your
> Postgres system configuration or your system in general.
>
> Please post:
> 1. Your postgres version
> 2. Your platform (OS and version)
> 3. Your hardware statistics, including:
>         Processor & RAM
>         Disk space free on your root drive and postgres drive
> 4. The view definition
> 5. Row counts on all tables involved in the view, as well as whether
> those tables have very large text fields or BLOBs.
> 6. Finally, check your Postgres log to see if VACUUM raised any errors,
> and to see if selecting the view causes any errors.
>
> -Josh Berkus
>
> ______AGLIO DATABASE SOLUTIONS___________________________
>                                        Josh Berkus
>   Complete information technology      josh@agliodbs.com
>    and data management solutions       (415) 565-7293
>   for law firms, small businesses        fax 621-2533
>     and non-profit organizations.      San Francisco