From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Matthias <nitrogenycs(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Hash Join cost estimates |
Date: | 2013-04-05 12:08:24 |
Message-ID: | 20130405120824.GN4361@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Matthias (nitrogenycs(at)gmail(dot)com) wrote:
> >In this example, hashing the large table is actually 2 seconds *faster*
> >than hashing the small table (again, all on my laptop).
>
> Are you running the laptop on battery? When I've benchmarked pgsql
> last time I used my laptop as well and it only occured to me after a
> lot of trying that laptops (even with all energy saving disabled in
> my case) don't always make for reliable benchmark machines. Things
> like your CPU clockspeed being dynamically adjusted can produce
> really strange results.
Those runs were with the laptop plugged in, but I've also run it w/o the
battery and while the performance is certainly different between those
two cases, the relative speed of hashing vs. hash-lookup has been
consistent. Also, that's why I provided the test case- feel free (and
please do!) test it on any/all hardware you can find. I'd love to hear
reports from others on their experiences. Also, the relative speeds on
my laptop runs matched the performance (the laptop was slower, but
slower in both paths in a comparable way) on the big server where this
is all originating.
> Of course your test case might not be affected by this at all, but
> it's something to watch out for.
Certainly.
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2013-04-05 13:09:11 | Re: corrupt pages detected by enabling checksums |
Previous Message | Noah Misch | 2013-04-05 11:59:04 | Re: matview scannability rehash (was Re: Drastic performance loss in assert-enabled build in HEAD) |