Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1XhXFC-0008Tw-V5 for pgsql-performance@arkaria.postgresql.org; Fri, 24 Oct 2014 05:16:59 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1XhXFB-0003ZH-QG for pgsql-performance@arkaria.postgresql.org; Fri, 24 Oct 2014 05:16:57 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1XhXF9-0003Z8-Io for pgsql-performance@postgresql.org; Fri, 24 Oct 2014 05:16:55 +0000 Received: from mout.gmx.net ([212.227.15.18]) by makus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1XhXF5-0003Q1-Sp for pgsql-performance@postgresql.org; Fri, 24 Oct 2014 05:16:53 +0000 Received: from [192.168.1.27] ([84.58.31.141]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LdYdG-1YPucN156Y-00ioDH for ; Fri, 24 Oct 2014 07:16:49 +0200 Message-ID: <5449E0C0.60904@gmx.de> Date: Fri, 24 Oct 2014 07:16:48 +0200 From: =?ISO-8859-1?Q?Bj=F6rn_Wittich?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: Re: extremly bad select performance on huge table References: <5446972B.9040409@gmx.de> <9706.1413918462@sss.pgh.pa.us> <5446B4B3.4030802@gmx.de> <54473B2E.2080007@gmx.de> <1413989639.83279.YahooMailNeo@web122306.mail.ne1.yahoo.com> <5447C9A6.3000107@gmx.de> In-Reply-To: <5447C9A6.3000107@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:UupqNfPXzk8TXmI45J/wCAgH2pAJ6mJ2+uqvzbJReLUzPvpQfhH +qLRaIIlECDZYQCCvTJQpy2EJd1VEAFsXVMtXFqSEhVuyaY29JFbOYblScGwhUemCb/19aA B3FH4hQX5vlPEmalgvS8uSuUvTEmDM1sSGaNDZ45tmurxWSnWlEMS+2Nz81Xw5mW+fBeBZ6 Gp45w7JS6OWD3ChHOPL2Q== X-UI-Out-Filterresults: notjunk:1; X-Pg-Spam-Score: -2.1 (--) 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, with a cursor the behaviour is the same. So I would like to ask a more general question: My client needs to receive data from a huge join. The time the client waits for being able to fetch the first row is very long. When the retrieval starts after about 10 mins, the client itself is I/O bound so it is not able to catch up the elapsed time. My workaround was to build a queue of small joins (assuming the huge join delivers 10 mio rows I now have 10000 joins delivering 1000 rows ). So the general question is: Is there a better solution then my crude workaround? Thank you > Hi Kevin, > > > this is what I need (I think). Hopefully a cursor can operate on a > join. Will read docu now. > > Thanks! > > > Björn > > Am 22.10.2014 16:53, schrieb Kevin Grittner: >> Björn Wittich wrote: >> >>> I do not want the db server to prepare the whole query result at >>> once, my intention is that the asynchronous retrieval starts as >>> fast as possible. >> Then you probably should be using a cursor. >> >> -- >> Kevin Grittner >> EDB: http://www.enterprisedb.com >> The Enterprise PostgreSQL Company >> >> > > > -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance