Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id 902B51337B2F for ; Thu, 3 Feb 2011 11:24:10 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 81189-07 for ; Thu, 3 Feb 2011 15:24:02 +0000 (UTC) X-Greylist: delayed 00:15:08.592272 by SQLgrey-1.7.6 Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mail.postgresql.org (Postfix) with ESMTP id E376A133740B for ; Thu, 3 Feb 2011 11:23:59 -0400 (AST) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Pl0ne-0008Fi-0B for pgsql-performance@postgresql.org; Thu, 03 Feb 2011 16:08:46 +0100 Received: from frigga.summersault.com ([12.161.105.138]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 03 Feb 2011 16:08:45 +0100 Received: from mark by frigga.summersault.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 03 Feb 2011 16:08:45 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: pgsql-performance@postgresql.org From: Mark Stosberg Subject: getting the most of out multi-core systems for repeated complex SELECT statements Date: Thu, 03 Feb 2011 10:08:35 -0500 Lines: 23 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: frigga.summersault.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 X-Enigmail-Version: 1.1.1 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.91 tagged_above=-10 required=5 tests=BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201102/75 X-Sequence-Number: 42213 Each night we run over a 100,000 "saved searches" against PostgreSQL 9.0.x. These are all complex SELECTs using "cube" functions to perform a geo-spatial search to help people find adoptable pets at shelters. All of our machines in development in production have at least 2 cores in them, and I'm wondering about the best way to maximally engage all the processors. Now we simply run the searches in serial. I realize PostgreSQL may be taking advantage of the multiple cores some in this arrangement, but I'm seeking advice about the possibility and methods for running the searches in parallel. One naive I approach I considered was to use parallel cron scripts. One would run the "odd" searches and the other would run the "even" searches. This would be easy to implement, but perhaps there is a better way. To those who have covered this area already, what's the best way to put multiple cores to use when running repeated SELECTs with PostgreSQL? Thanks! Mark