Re: One query run twice in parallel results in huge performance decrease

Поиск
Список
Период
Сортировка
Искать
От
Jan Michel
Тема
Re: One query run twice in parallel results in huge performance decrease
Дата
Msg-id
52991D59.9050100@mueschelsoft.de
Ответ на
Список
Дерево обсуждения
One query run twice in parallel results in huge performance decrease Jan Michel <Jan@mueschelsoft.de>
Re: One query run twice in parallel results in huge performance decrease Jeff Janes <jeff.janes@gmail.com>
Re: One query run twice in parallel results in huge performance decrease Jan Michel <Jan@mueschelsoft.de>
Re: One query run twice in parallel results in huge performance decrease Tom Lane <tgl@sss.pgh.pa.us>
Re: One query run twice in parallel results in huge performance decrease Jan Michel <Jan@mueschelsoft.de>
Re: One query run twice in parallel results in huge performance decrease Jeff Janes <jeff.janes@gmail.com>
Re: One query run twice in parallel results in huge performance decrease Jan Michel <Jan@mueschelsoft.de>
Re: One query run twice in parallel results in huge performance decrease Scott Marlowe <scott.marlowe@gmail.com>
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





В списке pgsql-performance по дате отправления
От: Jeff Janes
Дата:
От: Tom Lane
Дата:
FAQ