From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Piotr Foremniak <piotr(dot)foremniak(at)gmail(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: unstable SELECT performance under load |
Date: | 2008-12-09 22:35:10 |
Message-ID: | 22221.1228862110@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Piotr Foremniak <piotr(dot)foremniak(at)gmail(dot)com> writes:
> When executing some quite complex select queries our 8.3.5 Postgres
> often hangs. The query that we used to reproduce this problem on our
> isolated test environment is a quite complex join of ca.15 tables.
> When executed only once, it always takes ca. 500ms to finish. When
> executed by a JMeter stress test running a couple of threads
> simultaneously, ca. 95% of queries also take 500ms to finish. In the
> remaining 5% cases something weird happens and the same query finishes
> after several minutes, with the postgres process generating gigabytes
> of temp files and consuming 100% processor resources.
Hmm, are you *sure* you have geqo = off? Because this sure sounds like
geqo search sometimes getting lost in the weeds and picking a bad plan.
If it's really exactly the same query each time then you should be
getting the same plan and more or less the same execution time each
time.
Another possibility is that when you say "same query" you are ignoring
changes in parameter values that could result in the plan being
inappropriate for the new values.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Liraz Siri | 2008-12-09 22:51:59 | creating a specialized version of turnkey postgresql (Re: adding postgis support to turnkey postgresql) |
Previous Message | Dann Corbit | 2008-12-09 22:23:38 | Re: q query about a bug. |