Hi all, dear Richard,
your mail about my configuration parameter were the right hint, but i am still
struggling with the problem. i will appreciate if you or somebody else can
help me even further.
After some investigation i got some new results to my problem. The following
query is not workin
<[EMAIL PROTECTED]> writes:
> Could it be that something like this is happening:
> - In the early morning a new DB connection is opened.
> - While running VACUUM ANALYZE the planner uses different plans because some
> index could not be used or the statistics are right in that moment not
> prese
Am Mittwoch, 9. April 2008 10:11 schrieb David Wilson:
> On Wed, Apr 9, 2008 at 3:29 AM, <[EMAIL PROTECTED]> wrote:
> > But if i do "VACUUM ANALYZE" without concurrent queries, everything runs
> > fine afterwards.
> >
> > If i run "VACUUM ANALYZE" with few concurrent queries, it slows down to
>
On Wed, Apr 9, 2008 at 1:41 PM, David Wilson <[EMAIL PROTECTED]> wrote:
>
>
> I've run into a very similar problem. I have some long-running
> processes that generate a large amount of data and then query that
> data that must periodically drop their connections and rebuild to
> ensure that qu
On Wed, Apr 9, 2008 at 3:29 AM, <[EMAIL PROTECTED]> wrote:
> But if i do "VACUUM ANALYZE" without concurrent queries, everything runs fine
> afterwards.
>
> If i run "VACUUM ANALYZE" with few concurrent queries, it slows down to a
> crawl.
>
> Could it be that something like this is happeni
Am Dienstag, 8. April 2008 18:38 schrieb Scott Marlowe:
> It sounds to me like two possible problems, maybe combined.
>
> One possibility is that you have a data distribution that results in
> statistics being gathered that don't really represent your data. Try
> increasing the stats target for th
It sounds to me like two possible problems, maybe combined.
One possibility is that you have a data distribution that results in
statistics being gathered that don't really represent your data. Try
increasing the stats target for that column (or the whole db if you'd
rather) and re-running analyz
On Tuesday 08 April 2008, [EMAIL PROTECTED] wrote:
> The problem is that we have peaktimes were everything is running fine. It
> has something to do with the vacuum process running. To simplify my
> problem:
>
> - I run vaccum analyze concurrently with some few user queries: slows
> down to a crawl
HI Richard,
thanks for your immediate response. I will answer your questions below:
Am Dienstag, 8. April 2008 17:40 schrieb Richard Huxton:
> [EMAIL PROTECTED] wrote:
> > We looked in our cpu monitoring and saw that we have huge IOwait while
> > VACUUM is running, not unusual though. But just af
[EMAIL PROTECTED] wrote:
We looked in our cpu monitoring and saw that we have huge IOwait while VACUUM
is running, not unusual though. But just after VACUUM was finished, the
userCPU load raised to 200% (dual cpu). At this time in the early morning
there were only very few users using our app.
Hi all,
our postgresql DB was running fine for a long time, but suddenly we
encountered a huge problem which we got fixed only temporarily.
We are running debian stable with postgresql 8.1.11. Our app is connecting via
JDBC and uses Prepared Statements.
We are not running autovacuum but a nig
11 matches
Mail list logo
