From: | Sören Meyer-Eppler <soerenme(at)google(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: PostgreSQL 9.0.4 blocking in lseek? |
Date: | 2011-10-31 16:17:15 |
Message-ID: | 4EAECA0B.8050908@google.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
> Note the file number appearing in the lseeks, run "lsof -p PID" against
> the backend process to discover the actual filename of that file, then
> look for a match to the filename in pg_class.relfilenode.
Will do. I need to reproduce the error first which may take a while.
>> I have attached two of the offending execution plans. Anything obviously
>> wrong with them?
>
> What makes you say these are "offending execution plans"? Both of them
> seem to be completing just fine.
That's exactly the point. The plan looks good, the execution times will
usually be good. But sometimes, for no immediately obvious reasons,
they'll run for hours.
I know these are the offending queries because this is what
"select now() - query_start, current_query from pg_stat_activity"
will tell me.
We execute these queries from a Java program via JDBC
(postgresql-9.1-901.jdbc4.jar). But since little data is being
transferred between the Java client and the database I hope that cannot
be the issue.
Anything else I should look out for/log during the next test run?
Sören
From | Date | Subject | |
---|---|---|---|
Next Message | Jens Reufsteck | 2011-10-31 16:44:24 | Re: Anti join miscalculates row number? |
Previous Message | Albe Laurenz | 2011-10-31 15:34:55 | Re: SSL encryption makes bytea transfer slow |