On Fri, 2006-04-28 at 13:36, Greg Stumph wrote:
> Well, since I got no response at all to this message, I can only assume that
> I've asked the question in an insufficient way, or else that no one has
> anything to offer on our problem.
>
> This was my first post to the list, so if there's a better way I should be
> asking this, or different data I should provide, hopefully someone will let
> me know...
I'd pick one particular case and do explain analyze on it both right
after a reload, after running for a while, and after a vacuum analyze.
Also, do a vacuum verbose on the database and post the output of that
when the system's slowed down.
Do you make a lot of temp tables? Run a lot of DDL? I don't think we
have enough information to make a real informed decision, but I'm not
sure what questions to ask to find out where the bottleneck is...
Also, this could be the flash controller / card combo causing problems.
Do you start with a freshly formatted card at the beginning? I know
that flash controllers randomize the part of the card that gets written
to so that you don't kill one part of it early due to writing on just on
part. Could be that as the controller maps the card behind the scenes,
the access gets slower on the lower level, and there's nothing
PostgreSQL can do about it.
Can you tell us what your usage patterns are in a bit more detail?