Received: from localhost (unknown [200.46.204.191]) by postgresql.org (Postfix) with ESMTP id C76962E0234 for ; Sun, 2 Dec 2007 07:38:03 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.191]) (amavisd-maia, port 10024) with ESMTP id 20042-02 for ; Sun, 2 Dec 2007 07:37:57 -0400 (AST) Received: from aibo.runbox.com (aibo.runbox.com [193.71.199.94]) by postgresql.org (Postfix) with ESMTP id 23F1E2E022F for ; Sun, 2 Dec 2007 07:37:58 -0400 (AST) Received: from [10.9.9.130] (helo=fenris.runbox.com) by greyhound.runbox.com with esmtp (Exim 4.50) id 1Iyn92-0005LG-Ts for pgsql-performance@postgresql.org; Sun, 02 Dec 2007 12:37:56 +0100 Received: from mail by fenris.runbox.com with local (Exim 4.50) id 1Iyn92-00056Z-So for pgsql-performance@postgresql.org; Sun, 02 Dec 2007 12:37:56 +0100 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received: from [78.60.33.99] by secure.runbox.com with http (uid:663718) (RMM 4.0); for ; Sun, 02 Dec 2007 11:37:56 GMT From: "Mindaugas" To: pgsql-performance@postgresql.org Subject: Re: Dealing with big tables Date: Sun, 02 Dec 2007 13:37:56 +0200 (EET) X-Sender: 663718 X-Mailer: RMM References: <1196593535.7946.8.camel@whiteair> In-Reply-To: <1196593535.7946.8.camel@whiteair> Message-Id: X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200712/8 X-Sequence-Number: 27824 > my answer may be out of topic since you might be looking for a > postgres-only solution.. But just in case.... I'd like to stay with SQL. > What are you trying to achieve exactly ? Is there any way you could > re-work your algorithms to avoid selects and use a sequential scan > (consider your postgres data as one big file) to retrieve each of the > rows, analyze / compute them (possibly in a distributed manner), and > join the results at the end ? I'm trying to improve performance - get answer from mentioned query=20 faster. And since cardinality is high (100000+ different values) I doubt that it= =20 would be possible to reach select speed with reasonable number of nodes of= =20 sequential scan nodes. Mindaugas