From: Tom Lane <tgl@sss.pgh.pa.us>
To: Vamsidhar Thummala <vamsi@cs.duke.edu>
Cc: pgsql-performance@postgresql.org
Subject: Re: Hash Join performance
Date: Fri, 13 Mar 2009 19:08:11 -0400
Message-ID: <22599.1236985691@sss.pgh.pa.us> (raw)
In-Reply-To: <e0e3da5e0903131511q664ec424lfbf5b6c36da84598@mail.gmail.com>
References: <e0e3da5e0903131407k75ca87a4j5c7dcc360805d5c1@mail.gmail.com>
<e0e3da5e0903131415k38dc870bo15c6ad2625cd922b@mail.gmail.com>
<18410.1236980078@sss.pgh.pa.us>
<e0e3da5e0903131511q664ec424lfbf5b6c36da84598@mail.gmail.com>
Vamsidhar Thummala <vamsi@cs.duke.edu> writes:
> I am wondering why are we subtracting the entire Seq Scan time of Lineitem
> from the total time to calculate the HashJoin time.
Well, if you're trying to identify the speed of the join itself and not
how long it takes to provide the input for it, that seems like a
sensible calculation to make.
> Here is another plan I have for the same TPC-H 18 query with different
> configuration parameters (shared_buffers set to 400MB, just for experimental
> purposes) and HashJoin seems to take longer time (at least 155.58s based on
> above calculation):
Yeah, that seems to work out to about 25us per row instead of 3us, which
is a lot slower. Maybe the hash got split up into multiple batches ...
what have you got work_mem set to? Try turning on log_temp_files and
see if it records any temp files as getting created.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, vamsi@cs.duke.edu
Subject: Re: Hash Join performance
In-Reply-To: <22599.1236985691@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox