From: Rhett Garber <rhettg@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Havasvölgyi Ottó <h.otto@freemail.hu>
Cc: pgsql-performance@postgresql.org
Subject: Re: Why hash join instead of nested loop?
Date: Tue, 9 Aug 2005 12:11:52 -0700
Message-ID: <41b0fe8905080912113f381f84@mail.gmail.com> (raw)
In-Reply-To: <18143.1123614059@sss.pgh.pa.us>
References: <41b0fe890508051135712a086b@mail.gmail.com>
<15425.1123304631@sss.pgh.pa.us>
<41b0fe89050808100021a2a4fc@mail.gmail.com>
<10930.1123549106@sss.pgh.pa.us>
<41b0fe890508090951546156f7@mail.gmail.com>
<17253.1123607579@sss.pgh.pa.us>
<41b0fe89050809111027e1d274@mail.gmail.com>
<17825.1123612638@sss.pgh.pa.us>
<41b0fe89050809115174ae1669@mail.gmail.com>
<18143.1123614059@sss.pgh.pa.us>
Bingo, the smaller the sort_mem, the faster that query is.
Thanks a lot to everybody that helped, i'll tweak with these values
more when I get a chance now that I have some guidelines that make
sense.
Rhett
On 8/9/05, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Rhett Garber <rhettg@gmail.com> writes:
> > Well that could be an issue, is this abnormally large:
> > #shared_buffers = 1536 # min 16, at least max_connections*2, 8KB each
> > shared_buffers = 206440
> > #sort_mem = 131072 # min 64, size in KB
> > sort_mem = 524288 # min 64, size in KB
> > vacuum_mem = 131072 # min 1024, size in K
>
> The vacuum_mem number is OK I think, but both of the others seem
> unreasonably large. Conventional wisdom about shared_buffers is that
> the sweet spot is maybe 10000 or so buffers, rarely more than 50000.
> (Particularly in pre-8.0 releases, there are code paths that grovel
> through all the buffers linearly, so there is a significant cost to
> making it too large.) Don't worry about it being too small to make
> effective use of RAM --- we rely on the kernel's disk cache to do that.
>
> sort_mem is *per sort*, and so half a gig in a machine with only a
> couple of gig is far too much except when you know you have only one
> query running. A couple dozen backends each trying to use half a gig
> will drive you into the ground in no time. Conventional wisdom here
> is that the global setting should be conservatively small (perhaps
> 10Mb to 100Mb depending on how many concurrent backends you expect to
> have), and then you can explicitly increase it locally with SET for
> specific queries that need it.
>
> In terms of the problem at hand, try the test case with a few different
> values of sort_mem (use SET to adjust it, you don't need to touch the
> config file) and see what happens. I think the cost you're seeing is
> just startup overhead to zero a hash table of a few hundred meg ...
>
> 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: rhettg@gmail.com, tgl@sss.pgh.pa.us, h.otto@freemail.hu
Subject: Re: Why hash join instead of nested loop?
In-Reply-To: <41b0fe8905080912113f381f84@mail.gmail.com>
* 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