Received: from maia.hub.org (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id A0E7B633D21 for ; Tue, 23 Feb 2010 10:47:01 -0400 (AST) 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 61523-07 for ; Tue, 23 Feb 2010 14:46:50 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outbound-mail-352.bluehost.com (outbound-mail-352.bluehost.com [66.147.249.13]) by mail.postgresql.org (Postfix) with SMTP id ECDEC633D4B for ; Tue, 23 Feb 2010 10:46:50 -0400 (AST) Received: (qmail 22234 invoked by uid 0); 23 Feb 2010 14:40:08 -0000 Received: from unknown (HELO box398.bluehost.com) (69.89.31.198) by oproxy1.bluehost.com.bluehost.com with SMTP; 23 Feb 2010 14:40:08 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=negora.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=Oh55LoW9eNze6dbbA6vuIovDjM5TwxG2kfWAe+lLdTPPGmkv5e1hzCN3YPISgabTi9nIRYgZv7ANJXypr9Q2COywQoi8yS1tutDEKdEgkK21U6OTRckHUPevNiPzRwxE; Received: from 30.red-80-32-234.staticip.rima-tde.net ([80.32.234.30] helo=[172.16.0.2]) by box398.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Njvvk-0003rg-Gn for pgsql-performance@postgresql.org; Tue, 23 Feb 2010 07:40:08 -0700 Message-ID: <4B83E8C5.2050902@negora.com> Date: Tue, 23 Feb 2010 15:40:05 +0100 From: negora User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: Internal operations when the planner makes a hash join. Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {2410:box398.bluehost.com:negoraco:negora.com} {sentby:smtp auth 80.32.234.30 authed with negora+negora.com} X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.599 tagged_above=-10 required=5 tests=BAYES_00=-2.599 X-Spam-Level: X-Archive-Number: 201002/321 X-Sequence-Number: 37742 Hello: I'm an ignorant in what refers to performance analysis of PostgreSQL. I've a doubt about how the PostgreSQL planner makes a hash join. I've tried to "dig" into the archive of this mailing list but I haven't found what I'm looking for. So I'm explaining my doubt with an example to see if anyone can help me. Let's suppose that I've 2 tables, one of students and the other one of parents in a many-to-one relation. I want to do something like this: SELECT s.complete_name, f.complete_name FROM students AS s JOIN fathers AS f ON f.id_father = s.id_father; Using the ANALYZE command, I've checked that the planner firstly scans and extracts the required information from "fathers", builds a temporary hash table from it, then scans "students", and finally joins the information from this table and the temporary one employing the relation "f.id_father = s.id_father". My doubt is about this last step. When the planner checks the temporary table looking for the parent of a student: A) Does it run through the temporary father's table one time per student? This means that if there are 500 students, it's doing 500 loops on the temporary table. B) Or does it try to internally group students with the same father ID to avoid doing "absurd" loops on the temporary one? That's all. Thank you very much for your kindness :) .