Re: vacuum analyze slows sql query

Looking around at the pg_ tables and some PostgreSQL online
docs prompted by another post/reply on this list regarding
ALERT TABLE SET STATISTICS i found out that prior to a VACUUM
the following select (taken from the online docs) shows:

pkk=# select relname, relkind, reltuples, relpages from pg_class where relname
like 'pkk_%';
relname | relkind | reltuples | relpages
-------------------+---------+-----------+----------
pkk_billing | r | 1000 | 10
pkk_offer | r | 1000 | 10
pkk_offer_pkey | i | 1000 | 1
pkk_purchase | r | 1000 | 10
pkk_purchase_pkey | i | 1000 | 1
(5 rows)

Time: 1097.263 ms

and after a VACUUM:

pkk=# vacuum analyze ;
VACUUM
Time: 100543.359 ms

it shows:

pkk=# select relname, relkind, reltuples, relpages from pg_class where relname
like 'pkk_%';
relname | relkind | reltuples | relpages
-------------------+---------+-------------+----------
pkk_billing | r | 714830 | 4930
pkk_offer | r | 618 | 6
pkk_offer_pkey | i | 618 | 4
pkk_purchase | r | 1.14863e+06 | 8510
pkk_purchase_pkey | i | 1.14863e+06 | 8214
(5 rows)

Time: 3.868 ms

Further, I notice that if I were to delete rows from the
pg_statistic table I get the db in a state where the query
is fast again:

pkk=# explain analyze select offer_id, pkk_offer_has_pending_purch( offer_id )
from pkk_offer ;
QUERY PLAN

-----------------------------------------------------------------------------------------------------------------
Seq Scan on pkk_offer (cost=0.00..13.72 rows=618 width=4) (actual
time=2415.739..1065709.092 rows=618 loops=1)
Total runtime: 1065711.651 ms
(2 rows)

Time: 1065713.446 ms

pkk=# delete from pg_statistic where pg_statistic.starelid = pg_class.oid and
pg_class.relname like 'pkk_%';
DELETE 11
Time: 3.368 ms

pkk=# select offer_id, pkk_offer_has_pending_purch( offer_id ) from pkk_offer ;
(618 rows)

Time: 876.377 ms

pkk=# explain analyze select offer_id, pkk_offer_has_pending_purch( offer_id )
from pkk_offer ;
QUERY PLAN

----------------------------------------------------------------------------------------------------------
Seq Scan on pkk_offer (cost=0.00..13.72 rows=618 width=4) (actual
time=1.329..846.786 rows=618 loops=1)
Total runtime: 848.170 ms
(2 rows)

Time: 849.958 ms

Now, I'm sure someone (a PostgreSQL developer most likely)
is about to shoot me for doing such a thing :-)

But, however *ugly, wrong, sacrilege* this may be, if this is
the only solution...err workaround I have that will help me
i must resort to it.

The only two questions I have about this are:

1. Is this really the only solution left for me?
2. Am I in anyway screwing the db doing this?

Best regards,
--patrick

__________________________________
Do you Yahoo!?
Check out the new Yahoo! Front Page.
www.yahoo.com