Re: Database Optimization and Peformance

Thanks Jeff,

Obviously I have a bit to learn about Postgres admin.

 > How are your FSM settings in the conf file?

Looking at the postgresql.config the lines for max_fsm_pages and
max_fsm_relations are commented out so they have the default 20000 pages
and 1000 relations.  Should we up these defaults?

 >When you loaded the new data did you delete or update old data or was
it just a straight insert?

As far as the database load went, it was a straight insert, no updates
were made.

 >Can you run VACUUM VERBOSE and send us the last 10 or so lines of output?

I ran VACUUM FULL VERBOSE on the old production DB and I see we need to
run VACUUM FULL on a regular basis.  I took about hour and a half to
complete but afterwards the problem tables and queries are running
well.  Query time is  back to 1.08 mill sec.

Here are the last 10 lines of VACUUM FULL VERBOSE

Total free space (including removable row versions) is 0 bytes.
0 pages are or will become empty, including 0 at the end of the table.
0 pages containing 0 free bytes are potential move destinations.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO:  index "pg_toast_9187147_index" now contains 0 row versions in 1 pages
DETAIL:  0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO:  free space map: 1000 relations, 1111 pages stored; 19648 total
pages needed
DETAIL:  Allocated FSM size: 1000 relations + 20000 pages = 223 kB
shared memory.
VACUUM
erm_slow=>

Thanks again for your quick response

Regards
--Joe



Jeff Frost wrote:
> On Wed, 30 Aug 2006, Joe McClintock wrote:
>
>> I ran a vacuum, analyze and reindex on the database with no change in
>> performance, query time was still 37+ sec, a little worse. On our
>> test system I found that a db_dump from production and then restore
>> brought the database back to full performance. So in desperation I
>> shut down the production application, backed up the production
>> database, rename the production db, create a new empty production db
>> and restored the production backup to the empty db. After a
>> successful db restore and restart of the web application, everything
>> was then up and running like a top.
>
> Joe,
>
> I would guess that since the dump/restore yielded good performance
> once again, a VACUUM FULL would have also fixed the problem.  How are
> your FSM settings in the conf file?  Can you run VACUUM VERBOSE and
> send us the last 10 or so lines of output?
>
> A good article on FSM settings can be found here:
>
> http://www.pervasive-postgres.com/instantkb13/article.aspx?id=10087&cNode=5K1C3W
>
>
> You probably should consider setting up autovacuum and definitely
> should upgrade to at least 8.0.8 if not 8.1.4 when you get the chance.
>
> When you loaded the new data did you delete or update old data or was
> it just a straight insert?
>