Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VmX6N-0005X8-6Z for pgsql-performance@arkaria.postgresql.org; Fri, 29 Nov 2013 23:03:59 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1VmX6M-0008VY-Mc for pgsql-performance@arkaria.postgresql.org; Fri, 29 Nov 2013 23:03:58 +0000 Received: from makus.postgresql.org ([2001:4800:7903:4::125]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VmX6L-0008VS-S7 for pgsql-performance@postgresql.org; Fri, 29 Nov 2013 23:03:58 +0000 Received: from dd20832.kasserver.com ([85.13.140.227]) by makus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VmX6I-0004Ad-OX for pgsql-performance@postgresql.org; Fri, 29 Nov 2013 23:03:57 +0000 Received: from [192.168.1.3] (p4FDC273A.dip0.t-ipconnect.de [79.220.39.58]) by dd20832.kasserver.com (Postfix) with ESMTPA id 6D67D1CA0CE1; Sat, 30 Nov 2013 00:03:52 +0100 (CET) Message-ID: <52991D59.9050100@mueschelsoft.de> Date: Sat, 30 Nov 2013 00:03:53 +0100 From: Jan Michel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Jeff Janes CC: "pgsql-performance@postgresql.org" Subject: Re: One query run twice in parallel results in huge performance decrease References: <5299103F.1040307@mueschelsoft.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -0.0 (/) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org 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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance