To: "Joshua Marsh" <icub3d@gmail.com>
cc: "Terje Elde" <terje@elde.net>, "Jeff Davis" <pgsql@j-davis.com>,
	pgsql-performance@postgresql.org, jim@nasby.net
Subject: Re: Performance With Joins on Large Tables 
In-reply-to: <38242de90609131327o68d2866fh92c12ddcf364aba7@mail.gmail.com> 
References: <38242de90609121517y62517040v8622b9ae93cba23d@mail.gmail.com>
	<20060913064152.GC23173@nasby.net>
	<38242de90609130749u976295fwb10904ff4797b920@mail.gmail.com>
	<1158163655.29889.57.camel@dogma.v10.wvs>
	<38242de90609130919k33208204ka1006ff0ca25f75b@mail.gmail.com>
	<1158167054.29889.72.camel@dogma.v10.wvs>
	<45085F3A.1040108@elde.net>
	<38242de90609131327o68d2866fh92c12ddcf364aba7@mail.gmail.com>
Comments: In-reply-to "Joshua Marsh" <icub3d@gmail.com>
	message dated "Wed, 13 Sep 2006 14:27:47 -0600"
Date: Wed, 13 Sep 2006 17:09:44 -0400
Message-ID: <16645.1158181784@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Joshua Marsh" <icub3d@gmail.com> writes:
> I have a suspision that pgsql isn't tuned to properly deal with tables
> of this size.

Actually, it is.  Most of the planner complaints we get are from people
whose tables fit in memory and they find that the default planner
behavior doesn't apply real well to that case.  I find your
indexscan-is-faster-than-sort results pretty suspicious for large
tables.  Are the tables perhaps nearly in order by the dsiacctno fields?
If that were the case, and the planner were missing it for some reason,
these results would be plausible.

BTW, what are you using for work_mem, and how does that compare to your
available RAM?

			regards, tom lane