Re: slow seqscan

Hi Edoardo,

> The table is well indexed so that most of the queries are executed with
> index scan but since there is a big text field in the table (360chars)
> some search operation (with certain filters) ends up with seq scans.

Please paste the exact SELECT query that uses a seqscan, plus the
EXPLAIN ANALYZE of the SELECT, and the psql output of \d <table>.

> This table is not written during normal operation: twice per week there
> is a batch program that insert about 35.000 records and updates another
> 40.000.

After such an update, you need to run VACUUM ANALYZE <table>; Run it
before the update as well, if it doesn't take that long.

> last friday morning, after that batch has been executed, the database
> started responding really slowly to queries (expecially seq scans),
> after a "vacuum full analize" things did get something better.
> Yesterday the same: before the batch everything was perfect, after every
> query was really slow, I've vacuum it again and now is ok.
> Since now the db was working fine, it's 4 month's old with two updates
> per week and I vacuum about once per month.

You need to vacuum analyze (NOT full) once and HOUR, not once a month.
Add this command to your crontab to run once an hour and verify that
it's working:

vacuumdb -a -z -q

Otherwise, install the auto vacuum utility found in
contrib/pg_autovacuum in the postgres source. Set this up. It will
monitor postgres and run vacuums and analyzes when necessary. You can
then remove your cron job.

> I am using version 7.3 do I need to upgrade to 7.4? also, I was thinking
> about setting this table in a kind of "read-only" mode to improve
> performance, is this possible?

There's no read only mode to improve performance.

Upgrading to 7.4 will more than likely improve the performance of your
database in general. Be careful to read the upgrade notes because there
were a few incompatibilities.

Chris