On 1/26/11 12:13 PM, Tom Lane wrote:
> Josh Berkus writes:
>> Oh! Actually, it only *did* 27 runs. So it actually completed building
>> the index. I'd expected trace_sort to give me some kind of completion
>> message; apologies for not checking all screen windows.
>
> Huh, there should be an "
Josh Berkus writes:
> Oh! Actually, it only *did* 27 runs. So it actually completed building
> the index. I'd expected trace_sort to give me some kind of completion
> message; apologies for not checking all screen windows.
Huh, there should be an "external sort ended" message, as well as some
Tom,
> [ raised eyebrow... ] Those numbers are the differences between two
> gettimeofday() readings. It's really really hard to believe that that's
> wrong, unless there's something seriously wrong with your machine.
Actually, you're right ... I don't know what time the run27 message was
poste
Josh Berkus writes:
> ... I'll point out that the elapsed times which trace_sort is giving me
> are clearly not clock times; I started this index run at 7pm PST
> yesterday and it's been 15 hours, not 2 as the elapsed time would suggest.
[ raised eyebrow... ] Those numbers are the differences be
> Your logic has nothing to do with what is actually happening. Could we
> have a little bit more patience to see what happens next?
So, after 15 hours:
LOG: finished writing run 20 to tape 19: CPU 588.86s/4484.35u sec
elapsed 5160.97 sec
STATEMENT: create index "write_log_accounttime_idx" on
Josh Berkus writes:
> Well, for the straight test on event_time, the rows in the table should
> have been more-or-less physically already in order. This table is
> most-insert, and event_time mostly corresponds to current server time.
That would result in a very long initial run (probably all or
Josh Berkus writes:
> OK, either tape sort is broken or trace_sort is. The larger my
> maint_work_mem, the MORE tapes it wants to use:
Yeah, that's right. More tapes = better, or at least that was the
conclusion we came to some years ago. It doesn't necessarily use all
those tapes --- it's hop
>> 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?
OK, I'll let it run overnight and give you the t
Josh Berkus 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
On 1/25/11 1:21 PM, Tom Lane wrote:
> Josh Berkus writes:
>> Note: I have this running now on a test box. If someone responds in the
>> next couple hours, I can run whatever diagnostics you want on it.
>> Otherwise I'll kill it off and start over with debug logging turned on.
>
> trace_sort woul
> trace_sort would be interesting.
This is it so far:
LOG: begin index sort: unique = f, workMem = 1048576, randomAccess = f
STATEMENT: create index "write_log_accounttime_idx" on write_log
(account_id, event_time);
LOG: switching to external sort with 3745 tapes: CPU 9.06s/6.65u sec
elapsed
On 1/25/11 1:21 PM, Tom Lane wrote:
> Josh Berkus writes:
>> Note: I have this running now on a test box. If someone responds in the
>> next couple hours, I can run whatever diagnostics you want on it.
>> Otherwise I'll kill it off and start over with debug logging turned on.
>
> trace_sort woul
Josh Berkus writes:
> Note: I have this running now on a test box. If someone responds in the
> next couple hours, I can run whatever diagnostics you want on it.
> Otherwise I'll kill it off and start over with debug logging turned on.
trace_sort would be interesting.
re
Note: I have this running now on a test box. If someone responds in the
next couple hours, I can run whatever diagnostics you want on it.
Otherwise I'll kill it off and start over with debug logging turned on.
Version: 9.0.1
Platform: Solaris 10u8 / ZFS over DAS 7-drive array
Severity: Serious
Re
14 matches
Mail list logo
