Received: from localhost (unknown [200.46.204.191]) by postgresql.org (Postfix) with ESMTP id 6DDA69FBA00 for ; Wed, 17 Oct 2007 10:22:01 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.191]) (amavisd-maia, port 10024) with ESMTP id 07243-06 for ; Wed, 17 Oct 2007 10:21:56 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.5 Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by postgresql.org (Postfix) with ESMTP id E1F269FB9CE for ; Wed, 17 Oct 2007 10:21:56 -0300 (ADT) Received: by py-out-1112.google.com with SMTP id u77so4923705pyb for ; Wed, 17 Oct 2007 06:21:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=Nlf5qo+J0xNAD2upZEx2ClZAVRQtM3Dsaq72RyAZ9rY=; b=N6irtPqJ2MHA8gQy9uNsMZI3kAGhMAfhu1oXOE6kcxjWuBvQEnBwR7DT24wwi4tpLf6H8+FP1sAq6vrvFraTI76NCagso5IUJmAsVHF1MIuwTcipEB2CdrQjeGTxlBtxt8Xfxw39Q+W1ItnCfhourrnShWPgWDsDOLJYVZ2v1h4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=doxDBS9iuogw6a10dUvSZyrWQggHOMzAQF7N/RoIP07s2fbTtJkLRngBe4flEvy0FKLvWJ/QPvz8Hk5SXDggw1P82fTDm/Isn/BFEkaJzHUlIrdYyylnTDpVhB6uevYR7G0CnAXoEsl+K4OMzsWNQ2VUadJTDOXY63vVvjGl0YY= Received: by 10.35.86.12 with SMTP id o12mr10517078pyl.1192627315201; Wed, 17 Oct 2007 06:21:55 -0700 (PDT) Received: by 10.35.27.16 with HTTP; Wed, 17 Oct 2007 06:21:55 -0700 (PDT) Message-ID: <290a5abc0710170621o3e2534b1l91f3c0fcf93f532a@mail.gmail.com> Date: Wed, 17 Oct 2007 15:21:55 +0200 From: "Stefano Dal Pra" To: "Heikki Linnakangas" Subject: Re: two queryes in a single tablescan Cc: pgsql-sql@postgresql.org, pgsql-performance@postgresql.org In-Reply-To: <4716078A.1030505@enterprisedb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <290a5abc0710170530v215cb2b0q4fa000ad43096a28@mail.gmail.com> <4716078A.1030505@enterprisedb.com> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200710/200 X-Sequence-Number: 27222 On 10/17/07, Heikki Linnakangas wrote: > Stefano Dal Pra wrote: > > suppose you have a large table tab and two (or more) queryes like this: > > > > SELECT count(*),A FROM tab WHERE C GROUP BY A; > > SELECT count(*),B FROM tab WHERE C GROUP BY B; > > > > is there any way to get both results in a single query, > > eventually through stored procedure? > > The retrieved [count(*),A] ; [count(*),B)] data couldnt fit > > on a single table, of course. > > > > The main goal would be to get multiple results while scanning the > > table[s] once only > > thus getting results in a faster way. > > > > This seems to me quite a common situation but i have no clue whether a neat > > solution can be implemented through stored procedure. > > With a temp table: > > CREATE TEMPORARY TABLE tmp AS SELECT COUNT(*) as rows, a,b FROM WHERE C > GROUP BY a,b; > SELECT SUM(rows), a FROM tmp GROUP BY a; > SELECT SUM(rows), b FROM tmp GROUP BY b; > DROP TABLE tmp; > Thank You. I actually already do something like that: in a stored procedure i do create a md5 hash using passed parameters converted to TEXT and get a unix_like timestamp using now()::abstime::integer. This gets me a string like: 9ffeb60e9e6581726f7f5027b42c7942_1192443215 which i do use to EXECUTE CREATE TABLE 9ffeb60e9e6581726f7f5027b42c7942_1192443215 AS SELECT * FROM getjd('''||param1||''','''||param2||''','||param3||','||param4||')' The 9ffeb60e9e6581726f7f5027b42c7942_1192443215 is what i called 'tab' in my first post, and i need to perform about 7 queryes on that. (after a while i will drop the table using the timestamp part of the name, but that's another point). Here is where i would like to scan once only that table. Depending on parameters it may get as big as 50Mb (this actually is the tablespace size growth) or more with about 10^6 tuples. Stefano > (Using temp tables in plpgsql procedures doesn't quite work until 8.3. > But you can use dynamic EXECUTE as a work-around. There used to be a FAQ > entry about that, but apparently it's been removed because the problem > has been fixed in the upcoming release.) > > -- > Heikki Linnakangas > EnterpriseDB http://www.enterprisedb.com >