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@xxxxxxxxxxxxxx> 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
