| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Jim Nasby <jnasby(at)enova(dot)com> |
| Cc: | Merlin Moncure <mmoncure(at)gmail(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Problems with hash join over nested loop |
| Date: | 2013-10-30 23:06:39 |
| Message-ID: | 7541.1383174399@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Jim Nasby <jnasby(at)enova(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ben Hoyt | 2013-10-31 08:01:40 | Re: Re: Adding foreign key constraint holds exclusive lock for too long (on production database) |
| Previous Message | Jim Nasby | 2013-10-30 22:32:06 | Re: Problems with hash join over nested loop |