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.status AS status,
COALESCE(media_acts.art_checked_in, 0) AS art_in,
COALESCE(media_acts.art_waiting, 0) AS art_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
(SELECT intsetmedia.media AS mediaid,
media.status AS media_status,
mediatypemap.typecategory AS 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.activity AS 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(at)agliodbs(dot)com
> and data management solutions (415) 565-7293
> for law firms, small businesses fax 621-2533
> and non-profit organizations. San Francisco