Joe Conway wrote:
> It is possible for a query to run for many days, and still finish. This
> classifies as slow, not hung. The difference is important in
> troubleshooting to determine the cause.
OK, what do you suggest, how long should the process run, until I can
except it not to end?
>>>Also EXPLAIN output, and information regarding the number of rows in
>>>each table, and the number of rows matching veraid = 2 and veraid = 34
>>>might help.
>>
>> Explain produces the same problem. It just takes forever...
>
> Did you try EXPLAIN, or EXPLAIN ANALYZE? The former only does the
> planning, the latter actually materializes the result in order to get
> actual timings, and will therefore take at least as long as the query
> itself.
I got EXPLAIN to work. Please see the full update at Message-ID:
<4o2bkgFclmdhU1@individual.net>
So, I don't have to post on different Thread-Branches and can keep the
information together. Thanks ;)
>>>While the query is running, how much CPU is the process consuming, and
>>>what does vmstat show for disk and swap I/O?
>>
>> ~80% CPU power. Disk usage is not noticable.
>
> Can you attach with a debugger and see exactly what's going on? If not
> we'd need that self contained test case to reproduce the problem.
Sorry, I'm currently not able to attach a debugger. I think I'm right
that this means a recompilation of the package would be necessary. The
only thing I was seeing with strace was that the Process is permanently
accessing a file called:
postgresql/8.1/main/base/1740468/pgsql_tmp/pgsql_tmp21938.0
