| From: | "Joshua Marsh" <icub3d(at)gmail(dot)com> |
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| 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:18:49 |
| Message-ID: | 38242de90609131418j43d0dc88q3cb8a52dcceec287@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
> 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
>
My assumption would be they are in exact order. The text file I used
in the COPY statement had them in order, so if COPY preserves that in
the database, then it is in order.
The system has 8GB of ram and work_mem is set to 256MB.
I'll see if I can't make time to run the sort-seqscan method so we can
have an exact time to work with.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2006-09-13 21:23:44 | Re: Performance With Joins on Large Tables |
| Previous Message | Scott Marlowe | 2006-09-13 21:10:25 | Re: sql-bench |