Received: from maia.hub.org (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 43E97633358 for ; Tue, 30 Mar 2010 16:59:59 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 71168-01 for ; Tue, 30 Mar 2010 19:59:48 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-fx0-f225.google.com (mail-fx0-f225.google.com [209.85.220.225]) by mail.postgresql.org (Postfix) with ESMTP id 76410632F37 for ; Tue, 30 Mar 2010 16:59:48 -0300 (ADT) Received: by fxm25 with SMTP id 25so155150fxm.3 for ; Tue, 30 Mar 2010 12:59:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=cAU/D3beqQHy2mcdAp0VaXGZ0uORcKplHyKCETFljCg=; b=ZQY0fKopesdGUqrs8V/ezs5el08NYUxv+4DFKfRQ1OpNLLxA1ioi996pRP2vy78HND us2in204DloDTFNn1UViIyQux/06NhHQDau6OrHHv2kyh8O+0qqnwHyknGn/CQaqYW7n WNteGSJeKSfhe2u8ODAUd+ntWQZgPgbUi4itE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=A0ceOWUZRMZpPOcur+ietGSNuods+cbU1yzX1rWpUKqVkxRvjIah3zpESStBi1z30O deaTD2E13tjIOJXxlLHRFsws9vEMqEo8B0RC8NlRwbnOr2dfl6lam+vCDrHpJos/K1ig htk7ub6WEn8Je0PmrNZr9VJmBxX9/bTW50qOY= MIME-Version: 1.0 Received: by 10.239.161.83 with HTTP; Tue, 30 Mar 2010 12:59:46 -0700 (PDT) In-Reply-To: References: <603c8f071003291102g778afc2fvda0fc281454526c9@mail.gmail.com> <4BB1DB9A020000250003020E@gw.wicourts.gov> Date: Tue, 30 Mar 2010 15:59:46 -0400 Received: by 10.239.191.211 with SMTP id c19mr622350hbi.18.1269979186656; Tue, 30 Mar 2010 12:59:46 -0700 (PDT) Message-ID: <603c8f071003301259u140d8556vc54ff46855013bd3@mail.gmail.com> Subject: Re: experiments in query optimization From: Robert Haas To: Faheem Mitha Cc: Kevin Grittner , pgsql-performance@postgresql.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-0.185 tagged_above=-10 required=5 tests=BAYES_40=-0.185 X-Spam-Level: X-Archive-Number: 201003/400 X-Sequence-Number: 38225 On Tue, Mar 30, 2010 at 12:30 PM, Faheem Mitha wrote= : > Sure, but define sane setting, please. I guess part of the point is that = I'm > trying to keep memory low, and it seems this is not part of the planner's > priorities. That it, it does not take memory usage into consideration whe= n > choosing a plan. If that it wrong, let me know, but that is my > understanding. I don't understand quite why you're confused here. We've already explained to you that the planner will not employ a plan that uses more than the amount of memory defined by work_mem for each sort or hash. Typical settings for work_mem are between 1MB and 64MB. 1GB is enormous. >>>> You might need to create some indices, too. >>> >>> Ok. To what purpose? This query picks up everything from the >>> tables and the planner does table scans, so conventional wisdom >>> and indeed my experience, says that indexes are not going to be so >>> useful. >> >> There are situations where scanning the entire table to build up a >> hash table is more expensive than using an index. =A0Why not test it? > > Certainly, but I don't know what you and Robert have in mind, and I'm not > experienced enough to make an educated guess. I'm open to specific > suggestions. Try creating an index on geno on the columns that are being used for the jo= in. ...Robert