Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dkGLn-0000bu-Ag for pgsql-performance@arkaria.postgresql.org; Tue, 22 Aug 2017 21:04:39 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1dkGLm-000591-91 for pgsql-performance@arkaria.postgresql.org; Tue, 22 Aug 2017 21:04:38 +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 1dkGJz-00020b-VX for pgsql-performance@postgresql.org; Tue, 22 Aug 2017 21:02:48 +0000 Received: from mail-lf0-x22f.google.com ([2a00:1450:4010:c07::22f]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1dkGJw-00051j-IF for pgsql-performance@postgresql.org; Tue, 22 Aug 2017 21:02:46 +0000 Received: by mail-lf0-x22f.google.com with SMTP id g77so52335188lfg.1 for ; Tue, 22 Aug 2017 14:02:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=+kq+AaARjN8twVVRbkQw0XWuXPe9b100n8SbGcqtDoo=; b=vVTrxobfM71ICMZoPD8ENsfm3iTQxgM8NALSTwVix1lklsX88h/hAvYsWElzFKh0um r2iL6gFiJ58TYwemsrPRbfhEmQj9BHqedsxNv4YnzvG2cRIwBJNp57kzhUSaep78kzqI iayjqwa93uSRKEWI8hjSHbx/sTzEPnLPwn9Xiu6L90vScr43J1RAVsxeub2GnVix69VC Rg8ISEpV7MwAFCX6rHjdkdysNIQUIsFTSDshLLLKJoZW+kEr4OjS4eZvYsTt2TK3Ol8N TkKkUGpsNTy8t2s+/AnT+xMxmnyjkaFrnNtwTN+hUokXFXtxeptA2ure5PFSRXX2EmQW 8XDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=+kq+AaARjN8twVVRbkQw0XWuXPe9b100n8SbGcqtDoo=; b=ie3dmPsQVevRVo1m132VziUo5PR2aXPOOgSCsklPg3QS9ur7PaWHhlzP5Hi6zH3+le OcIvhiNoi/DZ06loR47Vo4qi2jPCr1hGoV/bff0LDFwx2kaZwE2f7hl2ktNYlG522LBL Z8IkMn8aP4kwXzGeT5OH3r9X2vAWVAV4lsvFvNT1BqlMvDsO+EkoXBXDN7fhyV1ZvWom zT2EwJqn0CjuzVi2iNH7l4SLsso3BY/DGCPSlr7QzKzTaVf/N6obklAjCc9zNk7N52wu eg5VrTOWYh6jWcZLBpc5Ah+U6ZGg+kDgvn4I7wOGajUsZZ30Fn1Q7HWqYORuZgcwV3wM 9n4g== X-Gm-Message-State: AHYfb5hnmN0HvdC3ngFJa5BP+U0LcMmffJYwjSOqNCPC6Cgdq2akY+WK rUHGsgMqo8lMUvHrR975/iwvDH8rP5AiDqMga5HCXr0Gzejr1/us+penxT0tdXXx68dEYTsgBJG 1OgMj0KW+YPL2GiWa3BUCASB13/qthKXiFyzadVkayy0zjlUHNQn9xigExMM2aLh5WXVnNgiCSL C1ScLPv6A= X-Received: by 10.25.83.1 with SMTP id h1mr134996lfb.183.1503435762092; Tue, 22 Aug 2017 14:02:42 -0700 (PDT) Received: from [10.137.1.17] (h-155-4-221-39.NA.cust.bahnhof.se. [155.4.221.39]) by smtp.gmail.com with ESMTPSA id 71sm3344350lfx.0.2017.08.22.14.02.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Aug 2017 14:02:41 -0700 (PDT) Subject: Re: query runs for more than 24 hours! To: Mariel Cherkassky , pgsql-performance@postgresql.org References: From: Tomas Vondra Message-ID: Date: Tue, 22 Aug 2017 23:02:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0a2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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 On 08/22/2017 04:23 PM, Mariel Cherkassky wrote: > Hi, I have a query that I run in my postgresql 9.6 database and it runs > for more than 24 hours and doesnt finish. > > My select consist from few joins : > I'm sorry, but the query and plans are completely broken (wrapped in funny ways, missing important bits. ...) I don't know what client you use or how that happened, but I recommend attaching the information as text files instead of pasting it into the message directly. Regarding the query analysis - we can't really help you much without seeing an explain analyze (that is, not just the plan and estimates, but actual performance and row counts). That usually identifies the query operations (scans, join, ...) causing issues. Of course, if the query is already running for 24h and you don't know how much longer it will take to complete, running EXPLAIN ANALYZE on it is not very practical. The best thing you can do is break the query into smaller parts and debugging that - start with one table, and then add tables/conditions until the performance gets bad. Hopefully the explain analyze on that will complete in reasonable time. Of course, you haven't told us anything about what's happening on the machine. It is reading a lot of data from the disks? Random or sequential? Is it writing a lot of data into temporary files? Is it consuming a lot of CPU? And so on. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance