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 1gQv9G-0004ei-Jk for pgsql-performance@arkaria.postgresql.org; Sun, 25 Nov 2018 14:12:34 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gQv9D-00071N-QS for pgsql-performance@arkaria.postgresql.org; Sun, 25 Nov 2018 14:12:31 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gQv9D-0006xE-DP for pgsql-performance@lists.postgresql.org; Sun, 25 Nov 2018 14:12:31 +0000 Received: from mail-io1-xd34.google.com ([2607:f8b0:4864:20::d34]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gQv9A-00082u-54 for pgsql-performance@lists.postgresql.org; Sun, 25 Nov 2018 14:12:29 +0000 Received: by mail-io1-xd34.google.com with SMTP id v10so6259197ios.13 for ; Sun, 25 Nov 2018 06:12:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=qNmjRagkyJIp7VPypskKHd3r7Q+Envv2FjxzUm9dcHc=; b=Jdh7WkU4BfRDaJVr5U3SVZEUb/cxwUtoKxPc+El6693JPLDf+IrBS/1TKaoNI8M73I xb9nEEIUzSHqEGKDtTQM4XfO3pi8dFNivUBi0+savB1ctd4aMzQ9LricUCqwLBB+Fdba mzz8zZgD3LMAnYni9EV2r0LJs875i0MZkeIryZvpg0sVnXFQcCf9qZ9G0vl27WE66kMJ YlNdn+rMsXqBQZj8SrS7rlKxF9tAwCZKAR7N54lElVNKPOeZDBzR3HeLMKV0maS2HpXY EsH1EKJarhwZOdPfmUo9cr4lpUfc+R0+gd61g76tSeGd7M8zxmlrx8GCQPKFMAKL8dec E34g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=qNmjRagkyJIp7VPypskKHd3r7Q+Envv2FjxzUm9dcHc=; b=GcrrYGxpaitLJiDnZqAjlL+r5Cxq4cI4ZEWVyxwb2ioaZwHKmbUPewGLtyhW3kH6ol 1pnUYZiaZRCG8K1Diy7VyRYrt5k8KW7WjnRztCeKbIiKedVpVjq+DOYwEXFIEZ+hNFya Y7iuaZDePHNOohTlBdazxADl2ZXSIM5D5YkH0a8LcSj8WEZnQgNduytMIGn0zpBw8V4W kVvQEPD8UP0QkBm4VOgMv1fcFWvqYUL4t1Cg8tDlLJQ/+fzJ/wlpQ1uPsJDBLNsmMq96 f13Of+5qIOc2quSHLoOkt6zZukL2aV6VHndsY1JuSFTmsnNXX/8JDK1tPK9r/gHn+d7W drcQ== X-Gm-Message-State: AA+aEWbdeaAOkQYruvmW9MURB5Yj1YedQupsh6YSkh0lAPcS3LX7ZaeK mi7MkqInqk8y6JGXfatze4qpCQ== X-Google-Smtp-Source: AFSGD/Utfagj+jMKTCeA0B3S4aE0lWf2FXipNS3upW/jewK5ks0GMNBnxIiOIfpqWGmWh93wMDbx9Q== X-Received: by 2002:a5e:8306:: with SMTP id x6mr15967212iom.229.1543155147184; Sun, 25 Nov 2018 06:12:27 -0800 (PST) Received: from pryzbyj (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id p74sm13245069iod.14.2018.11.25.06.12.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 25 Nov 2018 06:12:26 -0800 (PST) Received: by pryzbyj (Postfix, from userid 1000) id DC59F802543; Sun, 25 Nov 2018 08:12:25 -0600 (CST) Date: Sun, 25 Nov 2018 08:12:25 -0600 From: Justin Pryzby To: Mariel Cherkassky Cc: pgsql-performance@lists.postgresql.org Subject: Re: explain analyze faster then query Message-ID: <20181125141225.GQ10913@telsasoft.com> References: <20181125133002.GP10913@telsasoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Sun, Nov 25, 2018 at 03:37:46PM +0200, Mariel Cherkassky wrote: > I run it from inside the machine on the local database. > For example : > > db=# create table rule_test as select generate_series(1,100000000); > SELECT 100000000 > db=# explain analyze select generate_series from rule_test order by > generate_series asc; So it's returning 100M rows to the client, which nominally will require moving 400MB. And pgsql is formatting the output. I did a test with 10M rows: [pryzbyj@database ~]$ command time -v psql postgres -c 'SELECT * FROM rule_test' |wc -c& Command being timed: "psql postgres -c SELECT * FROM rule_test" User time (seconds): 11.52 Percent of CPU this job got: 78% Elapsed (wall clock) time (h:mm:ss or m:ss): 0:17.25 Maximum resident set size (kbytes): 396244 ... 170000053 Explain analyze takes 0.8sec, but returning query results uses 11sec CPU time on the *client*, needed 400MB RAM (ints now being represented as strings instead of machine types), and wrote 170MB to stdout, Also, if the output is being piped to less, the data is going to be buffered there, which means your query is perhaps using 4GB RAM in psql + 4GB in less.. Is the server swapping ? check "si" and "so" in output of "vmstat -w 1" Justin