Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e2Exc-0008Gw-V4 for pgsql-performance@arkaria.postgresql.org; Wed, 11 Oct 2017 11:14:01 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1e2Exc-0003Tl-8q for pgsql-performance@arkaria.postgresql.org; Wed, 11 Oct 2017 11:14:00 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1e2Evq-0000Nx-Um for pgsql-performance@postgresql.org; Wed, 11 Oct 2017 11:12:11 +0000 Received: from mail-wm0-x22a.google.com ([2a00:1450:400c:c09::22a]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1e2Eve-0003mI-UU for pgsql-performance@postgresql.org; Wed, 11 Oct 2017 11:12:09 +0000 Received: by mail-wm0-x22a.google.com with SMTP id k4so3747996wmc.1 for ; Wed, 11 Oct 2017 04:11:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3NPs30uIGVng72lzmoYFpDdnvw49FwBkIeAZZJvgekM=; b=phzEePVqMx6N8rQ8hzCOU+3XUImR+QDocS9quEYsN1VTh2uLLQnnVEq80njscLWCLB a7KnI9JPDiwQf6o41A6wcz3GKVYUBNtDF8vpGPXnrkzDY+5f8iMLV8I8xCzoE0SK8Y5K YU5n5VEw/wLm3w3un9zqAtxY0iklFgAT9r2ETp425no4fOoD0MTOUdurmsGZU+4x0UYg fqy/raErJyWVXBoCZuMAUfpj74yqXBJcHF71SPk3VkTav3pk5JmBmbn/+z6Hy4tkBhkh 2whWJPxocOJqGN1hc0c7QwE4NT3ozSrf5h9CrzUjk/6nLN23nl4lAXWPDnIP+X12kPIC 1rbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3NPs30uIGVng72lzmoYFpDdnvw49FwBkIeAZZJvgekM=; b=G0YbNy9H6snzskuZeppVuMM/MUGgcyzRDRFcBJ2dImL9RFyYeMGo/tDSxn4XMw3JpK 5tmBjpTNAsay/W0OKYWa5h261CBZ7Ze6PJyvO6hx0c+GddFZAbcwiJRcKooONMxeB80B PD2Fa2USNDtQXhC9q3tyt++Gsd3NzfGo1NEAs818KxQlBUUz00ETdEpOGvOvIkAZid1h pohNPjB4otWqjfQw4qFYuOsIzx+7HuwwRRD5xrpOKEKoIHCY/eDuvBprjUjaDajY48hP YdpP2lhanpestjt+SIxPSmFPQCu4EUhVuNEHCHUKu5sezSyULoxtlZBcb0smdVqv6osl OUgQ== X-Gm-Message-State: AMCzsaUrTFpNjggR27f/GMFcHl9o6ZS77e9uA/0WWpQvsHm1Lw+xGrN9 SnqVaMF1a4eFkAi5r9AVVE1K2cSSC/aZY174Fhc= X-Google-Smtp-Source: AOwi7QDOU4Ine+p+Q/SogjluD3Y8mTKcei/DLiS7keVh5+pEYr4xAsM7HhKibRy9XgefE0cgkkRFggxq1I06WVq1wrY= X-Received: by 10.223.144.226 with SMTP id i89mr7952065wri.217.1507720317457; Wed, 11 Oct 2017 04:11:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.146.7 with HTTP; Wed, 11 Oct 2017 04:11:17 -0700 (PDT) In-Reply-To: References: From: Pavel Stehule Date: Wed, 11 Oct 2017 13:11:17 +0200 Message-ID: Subject: Re: performance drop after upgrade (9.6 > 10) To: =?UTF-8?Q?johannes_gra=C3=ABn?= Cc: "pgsql-performance@postgresql.org" Content-Type: multipart/alternative; boundary="94eb2c05f482f15a43055b437d48" 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 --94eb2c05f482f15a43055b437d48 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 2017-10-11 13:06 GMT+02:00 johannes gra=C3=ABn : > Hi, > > I wrote a query that joins several tables usually returning less than > 1000 rows, groups them and generates a JSON object of the result. In > 9.6 is was a question of milliseconds for that query to return the > requested data. Now, after upgrading to 10, the query never returns - > at least it hasn't returned in the last hour. > > To see what happens, I requested the query plan [1]. It looks complex > and shows a lot of parallelization. I don't have the query plan from > 9.6, but I remember it being considerably simpler. > > Can anyone have a guess what altered the performance here so > dramatically? Is there a way to disable new parallelization features > just for this query to see if it makes any difference? > > have you fresh statistics? After upgrade is necessary to run ANALYZE comman= d Regards Pavel Best > Johannes > > > [1] https://explain.depesz.com/s/xsPP > > > -- > Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org= ) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-performance > --94eb2c05f482f15a43055b437d48 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


2017-10-11 13:06 GMT+02:00 johannes gra=C3=ABn <johannes@selfnet.de<= /a>>:
Hi,

I wrote a query that joins several tables usually returning less than
1000 rows, groups them and generates a JSON object of the result. In
9.6 is was a question of milliseconds for that query to return the
requested data. Now, after upgrading to 10, the query never returns -
at least it hasn't returned in the last hour.

To see what happens, I requested the query plan [1]. It looks complex
and shows a lot of parallelization. I don't have the query plan from 9.6, but I remember it being considerably simpler.

Can anyone have a guess what altered the performance here so
dramatically? Is there a way to disable new parallelization features
just for this query to see if it makes any difference?



have you fresh statisti= cs? After upgrade is necessary to run ANALYZE command

Regards

Pavel


Best
=C2=A0 Johannes


[1] https://explain.depesz.com/s/xsPP


--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-pe= rformance

--94eb2c05f482f15a43055b437d48--