Aaron Krowne wrote:
>>- What version of Postgres?
> 7.2.1
You should definitely look at upgrading, at least to 7.2.4 (which you
can do without requiring a dump/reload cycle), but better yet to 7.3.2
(which will require a dump/reload cycle). I don't know that will fix you
specific issue, but there were some critical bug fixes between 7.2.1 and
7.2.4.
>>- Does the database see mostly SELECTs and INSERTs, or are there many
>> UPDATEs and/or DELETEs too?
>
> Almost exclusively SELECTs.
>
> OK, I have just run a VACUUM FULL ANALYZE and things seem much better...
Hmmm, do you periodically do large updates or otherwise turn over rows
in batches?
> which would be the first time its really made a difference =) I tried
> comparing an EXPLAIN ANALYZE of a single row select on the main objects
> table before and after the vacuum, and the plan didn't change
> (sequential scan still), but the response time went from ~1 second to
> ~5msec! I'm not really sure what could have happened here
> behind-the-scenes since it didn't start using the index, and there
> probably weren't more than 10% updated/added rows since the last VACUUM.
If your app is mostly doing equi-lookups by primary key, and indexes
aren't being used (I think I saw you mention that on another post), then
something else is still wrong. Please pick one or two typical queries
that are doing seq scans and post the related table definitions,
indexes, SQL, and EXPLAIN ANALYZE. I'd bet you are getting bitten by a
datatype mismatch or something.
Joe
