Josh Berkus <[email protected]> writes:
> LOG: finished writing run 1 to tape 0: CPU 33.39s/149.02u sec elapsed
> 190.11 sec
> LOG: finished writing run 2 to tape 1: CPU 62.72s/371.06u sec elapsed
> 443.16 sec
> LOG: finished writing run 3 to tape 2: CPU 91.04s/599.43u sec elapsed
> 701.37 sec
> LOG: finished writing run 4 to tape 3: CPU 120.95s/823.59u sec elapsed
> 956.67 sec
> If it's going to take 3 minutes each to write each of 3745 tapes, that
> means completing in around 9 days.
Your logic has nothing to do with what is actually happening. Could we
have a little bit more patience to see what happens next?
> ... run 2 didn't complete in even 1/2 hour.
That's *good*, not bad. Long runs mean fewer merge steps.
(Memo to -hackers: what we lack in this trace is any indication of how
long the runs are. Maybe should add that. Knuth claims the initial
runs should amount to about 2X maintenance_work_mem on average, but
maybe there's something unusual about the data distribution here.)
regards, tom lane
--
Sent via pgsql-bugs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
