From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jim Nasby <jnasby@enova.com>
cc: Merlin Moncure <mmoncure@gmail.com>,
 "pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Subject: Re: Problems with hash join over nested loop
In-reply-to: <527188E6.2030209@enova.com>
References: <526EDDF7.3090102@enova.com> <13775.1383002035@sss.pgh.pa.us>
 <CAHyXU0ydScKt=-5G4yBpHWAh9eO6eV60P6uVCnui+YS9EMY5vw@mail.gmail.com>
 <526FE086.4020903@enova.com> <3692.1383065114@sss.pgh.pa.us>
 <526FE7D0.9000605@enova.com> <5575.1383070823@sss.pgh.pa.us>
 <527015BC.3020405@enova.com> <8314.1383078998@sss.pgh.pa.us>
 <527187ED.1000907@enova.com> <527188E6.2030209@enova.com>
Comments: In-reply-to Jim Nasby <jnasby@enova.com>
 message dated "Wed, 30 Oct 2013 17:32:06 -0500"
Date: Wed, 30 Oct 2013 19:06:39 -0400
Message-ID: <7541.1383174399@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

Jim Nasby <jnasby@enova.com> writes:
> Oh, and in my 28 table case ru_minflt was 428 4k memory pages (1.7MB). Not a great measurement, but better than nothing. I didn't detect anything noticeable on vmstat either, so I don't think the consumption is huge (an email in the older thread mentioned 1GB... I'm not seeing that).

Note that what matters here is not so much the number of base relations as
the number of possible join paths, which varies quite a lot depending on
the given and deduced join conditions.  Worst-case is where join
conditions are available between any two base relations, which is not
a real common case.

			regards, tom lane


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance