Re: vacuum analyze slows sql query - Mailing list pgsql-performance

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