| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Joshua Marsh" <icub3d(at)gmail(dot)com> |
| Cc: | "Terje Elde" <terje(at)elde(dot)net>, "Jeff Davis" <pgsql(at)j-davis(dot)com>, pgsql-performance(at)postgresql(dot)org, jim(at)nasby(dot)net |
| Subject: | Re: Performance With Joins on Large Tables |
| Date: | 2006-09-13 21:09:44 |
| Message-ID: | 16645.1158181784@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
"Joshua Marsh" <icub3d(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Scott Marlowe | 2006-09-13 21:10:25 | Re: sql-bench |
| Previous Message | Ivan Voras | 2006-09-13 21:02:01 | Re: Poor performance on seq scan |