Re: won't drop the view

Oleg Lebedev <olebedev@waterford.org> writes:
> Deleting from pg_statistic restored view performance to the way it was
> before I ran vacuum analyze.
> Below I attach two files that contain explain statistics for the view before
> (progress_report.txt) and after (progress_report_analyzed.txt) I ran vacuum
> analyze. The first one takes about 15 secs. to complete, the second one
> takes 12-13 minutes to complete.

Looks like the issue is the number of rows estimated to be obtained from
the "activity" table:

good plan:

>         ->  Merge Join  (cost=14644.00..14648.62 rows=4 width=128)
>               ->  Sort  (cost=11.02..11.02 rows=2 width=48)
>                     ->  Seq Scan on activity  (cost=0.00..11.00 rows=2 width=48)
>               ->  Sort  (cost=14632.99..14632.99 rows=367 width=112)
>                     ->  Subquery Scan media_acts  (cost=14553.17..14617.36 rows=367 width=112)

bad plan:

>         ->  Nested Loop  (cost=14605.17..14686.99 rows=2 width=128)
>               ->  Seq Scan on activity  (cost=0.00..11.00 rows=1 width=48)
>               ->  Subquery Scan media_acts  (cost=14605.17..14671.27 rows=378 width=112)

The plans for media_acts look about the same, so I have to guess that
activity actually yields 50 or so rows, not just one.  That doesn't
hurt the mergejoin too much, but it is a killer for the nestloop.

You showed the query as (SELECT ...       FROM activity       WHERE   activity.productcode ~ '^m3') acts
How many rows actually match activity.productcode ~ '^m3' ?  How many
rows altogether in activity?
        regards, tom lane