Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iwMNa-0001ah-W7 for pgsql-performance@arkaria.postgresql.org; Tue, 28 Jan 2020 08:37:51 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1iwMNZ-00016X-CK for pgsql-performance@arkaria.postgresql.org; Tue, 28 Jan 2020 08:37:49 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iwMNY-00015b-WD for pgsql-performance@lists.postgresql.org; Tue, 28 Jan 2020 08:37:49 +0000 Received: from mail-wm1-x32c.google.com ([2a00:1450:4864:20::32c]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1iwMNV-0006Vo-07 for pgsql-performance@lists.postgresql.org; Tue, 28 Jan 2020 08:37:47 +0000 Received: by mail-wm1-x32c.google.com with SMTP id q9so1487966wmj.5 for ; Tue, 28 Jan 2020 00:37:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec-at.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:to:date:in-reply-to:references:user-agent :mime-version:content-transfer-encoding; bh=0U8mtFCt0msgw9nwfQs5wl8c9ywKpCDrPyEzJHy2ePM=; b=dpypxK1Fnl8R31KULCkABEz85Zn8DwFzcJoW20Z2efddi90tsKT1KLOsVz5oEYMiKj l1drMvk3rotPuCUyslc+9p0VpRi5SmckK1hxwPgktUPSqvR41zWQ8HaUKzzOorpbEKn9 8mmL/Uwy95jpKcwjoLUoPEzFLOdDFwaPgWwSslU5NHlHfDFmwQprtVTa6gvGUVCdn7Vk ftxWUxq5m4eMItjDi30m7ANaaSRkVeQn3hxNMh7FqH81LYeAQquMhL3ipL7G/HX1JMut AWMmqDQZF3FM9zj9kJAHOQsRCt3vBHyCgA/I++Nmvm6W/Tskw7LlsjC4VGm372zV6vgD tVow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=0U8mtFCt0msgw9nwfQs5wl8c9ywKpCDrPyEzJHy2ePM=; b=IAIjgQcM1STblV0WQlxQkvRMnErxBW8tIaBkHMLjmBWGTxc5WNmfwyOhTfLaFLwZoV 12dmIxkFLFtV9FmN1GYgeWK1TwY2hrhDaExDZtCrF5pzGmnvkl0qzXU2P6hAc9UR0San wTvhNW737vxcxExNk3IKlohxNQHvDkPedYRr6f2fQd1XQ6Y/+3l7ftomaBE4idcusSgM hb+aQmuoRFfGqtoFyf1p1/8iKqDjctYqNEqVyOEbaur+8Dg6DtAGrIgBF45cDP41g2fV yFEOaIM7jpSuAlCX7+HTeSGyX0DzPpSoToc0hr8EEV19bzGZ2lQPbidYZCk44+NhSEgj r0uw== X-Gm-Message-State: APjAAAWYPqa3K9TUjxW3RUrIuCUC8pmzOkbiqfD993pb2ZV7LtX54qsc R7vPe2qEt862GC9GFXO2YoPH9w== X-Google-Smtp-Source: APXvYqytYYV6pZseFUxRLkKWkU/IB2lJ3a6YM3V3I1tkhfH1YESfierWrNLd/T97setGo/YrD/kzqw== X-Received: by 2002:a1c:e28a:: with SMTP id z132mr3459865wmg.157.1580200663841; Tue, 28 Jan 2020 00:37:43 -0800 (PST) Received: from localhost.localdomain ([212.186.219.234]) by smtp.gmail.com with ESMTPSA id b10sm26309320wrt.90.2020.01.28.00.37.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Jan 2020 00:37:43 -0800 (PST) Message-ID: <9e8e2cc3aa05f979cef2cfe95e443ba5250f33fb.camel@cybertec.at> Subject: Re: Query optimization advice for beginners From: Laurenz Albe To: Kemal Ortanca , "pgsql-performance@lists.postgresql.org" Date: Tue, 28 Jan 2020 09:37:42 +0100 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.32.5 (3.32.5-1.fc30) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Mon, 2020-01-27 at 13:15 +0000, Kemal Ortanca wrote: > There is a query that runs slowly when I look at the logs of the database. When I check the > resources of the system, there is no problem in the resources, but this query running slowly. > There is no "Seq Scan" in the queries, so the tables are already indexed. But I did not > fully understand if the indexes were made correctly. When I analyze the query result on > explain.depesz, it seems that the query is taking too long. > > How should I fix the query below? How should I read the output of explain.depesz? > > https://explain.depesz.com/s/G4vq Normally you focus on where the time is spent and the mis-estimates. The mis-estimates are notable, but this time not the reason for a wrong choice of join strategy: evern though there are overestimates, a nested loop join is chosen. The time is spent in the 16979 executions of the outer subquery, particularly in the inner subquery. Because the query uses correlated subqueries, PostgreSQL has to execute these conditions in the fashion of a nested loop, that is, the subquery is executed for every row found. If you manage to rewrite the query so that it uses (outer) joins instead of correlated subqueries, the optimizer can use different strategies that may be more efficient. Yours, Laurenz Albe -- Cybertec | https://www.cybertec-postgresql.com