| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc> |
| Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: problem with large maintenance_work_mem settings and |
| Date: | 2006-03-10 14:31:44 |
| Message-ID: | 4961.1142001104@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc> writes:
> LOG: begin index sort: unique = f, workMem = 8024000, randomAccess = f
> LOG: switching to external sort with 28658 tapes: CPU 4.18s/13.96u sec
> elapsed 32.43 sec
> LOG: finished writing run 1 to tape 0: CPU 173.56s/3425.85u sec elapsed
> 3814.82 sec
> LOG: performsort starting: CPU 344.17s/7013.20u sec elapsed 7715.45 sec
> LOG: finished writing final run 2 to tape 1: CPU 347.19s/7121.78u sec
> elapsed 7827.25 sec
> LOG: performsort done (except 2-way final merge): CPU 348.25s/7132.99u
> sec elapsed 7846.47 sec
> after that the postmaster is now consuming 99% CPU for about 22 hours(!)
I'll look into it, but I was already wondering if we shouldn't bound the
number of tapes somehow. It's a bit hard to believe that 28000 tapes is
a sane setting.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stefan Kaltenbrunner | 2006-03-10 14:45:37 | Re: problem with large maintenance_work_mem settings and |
| Previous Message | Zeugswetter Andreas DCP SD | 2006-03-10 11:59:32 | Re: Merge algorithms for large numbers of "tapes" |