Hi Jeff,
thanks for the answer.
On 29.11.2013 23:42, Jeff Janes wrote:
The planner is not aware of what else is going on in the server
I was not aware of this as well.
I'd guess that the 2nd database is missing the geometry index, or has
it defined in some different way such that the database doesn't think
it can be used.
Unfortunately - no. E.g. the first problematic plan I posted is from the
same schema loaded with the same data as the one that works well.
All tables are generated freshly from scratch by the same script only
minutes before this query is run. I tested them all individually and
never saw any problem, all use the same plan. As soon as I run two in
parallel it happens. I also did a test by feeding two tables with
identical data - again the same problem.
First I used tables in different schemas, then I tested to run them in
different databases. It had no influence. The thing is 100% reproducable
on three different machines with different hardware, different OS and
different pgsql versions. A single query is fast, as soon as a second
one comes in parallel it gets stuck. Every other query I have in the
toolchain does not show this behavior - and there are some quite
expensive ones as well.
Jan
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
