From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Hash Join cost estimates |
Date: | 2013-04-04 18:36:22 |
Message-ID: | 20130404183622.GJ4361@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> > What I'm trying to get at in this overall email is: why in the world is
> > it so expensive to do hash lookups?
>
> perf or oprofile reveal anything?
Working on a test case actually- I've got one now:
http://snowman.net/~sfrost/test_case2.sql
In this example, hashing the large table is actually 2 seconds *faster*
than hashing the small table (again, all on my laptop).
> Also, I assume that the cases you are looking at are large enough that
> even the "small" table doesn't fit in a single hash batch?
No, quite the opposite, sorry for not mentioning that before. Either
side fits completely into memory w/ a single batch. The explain
analyze's that I posted before show that, either way, there's only one
batch involved.
> (You never did mention what work_mem setting you're testing, anyway.)
With the test case above (where I got a 2s faster run time by hashing
the big table) used a work_mem of 1GB.
Thanks!
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Dimitri Fontaine | 2013-04-04 18:53:18 | Re: Multi-pass planner |
Previous Message | Tom Lane | 2013-04-04 18:19:36 | Re: Hash Join cost estimates |