More full text index..

I hadn't concentrated on the INSERT/UPDATE/DELETE speed of this until today
and I find that it's amazingly slow. Of course the time it takes is relative
to the size of the text but still, almost a minute to delete one record on a
Dual celeron 600 with 256 Megs of RAM and an ATA/66 7200 RPM 30 GIG hard
drive... INSERTs seem to be quite a bit faster (which puzzles me) but
they're still 10-20 seconds for a single record... UPDATEs seems very fast
(a few seconds).

I do have a lot of stop works in fti.c, however when I imported the 10,000
text files into the data base it was super fast (before I created indexes)
so I'm assuming that the indexes are slowing down the INSERTs UPDATEs and
DELETEs, which is expected I think? The database is VACUUMed on a regular
basis (and VACUUM ANALYZEed as well).

I'd rather have the fast search than the fast data entry, I just want to be
absolutely sure that I can't do anything to speed things along..

If I run PGOPTIONS="-d2 -s" psql databasename

I get this in the logs on an INSERT -- it doesn't appear to give any stats
on the queries that the function called by the fti trigger is doing..


--Here is my insert query (20k of text) --
query: INSERT INTO resumes_fti (string, id) VALUES ($1, $2)
! system usage stats:
!       0.644167 elapsed 0.380151 user 0.126785 system sec
!       [0.387579 user 0.149069 sys total]
!       9/2 [13/2] filesystem blocks in/out
!       0/2228 [0/2459] page faults/reclaims, 0 [0] swaps
!       0 [0] signals rcvd, 0/0 [3/3] messages rcvd/sent
!       9/4 [16/7] voluntary/involuntary context switches
! postgres usage stats:
!       Shared blocks:         20 read,          0 written, buffer hit rate
= 99.77%
!       Local  blocks:          0 read,          0 written, buffer hit rate
= 0.00%
!       Direct blocks:          0 read,          0 written
CommitTransactionCommand
proc_exit(0)

Like I said, I just need to know if this is expected or if there might be
something (anything) I can do to speed it up.. It's going to be running on a
damn fast machine so I'm sure that these times are going to get smaller, if
not from just brute force.

Thanks guys!

-Mitch