Tom Lane wrote: > I increased the size of the test case by 10x (basically s/100000/1000000/) > which is enough to push it into the external-sort regime. I get > amazingly stable runtimes now --- I didn't have the patience to run 100 > trials, but in 30 trials I have slowest 11538 msec and fastest 11144 msec. > So this code path is definitely not very sensitive to this data > distribution. > > While these numbers aren't glittering in comparison to the best-case > qsort times (~450 msec to sort 10% as much data), they are sure a lot > better than the worst-case times. So maybe a workaround for you is > to decrease maintenance_work_mem, counterintuitive though that be. > (Now, if you *weren't* using maintenance_work_mem of 100MB or more > for your problem restore, then I'm not sure I know what's going on...) > Good call. I basically reversed your test by keeping the number of rows the same (200000), but reducing maintenance_work_mem. Reducing to 8192 made no real difference. Reducing to 4096 flattened out all the times nicely. Slower overall, but at least predictable. Hopefully only a temporary solution until qsort is fixed. My restore now takes 22 minutes :) I think the reason I wasn't seeing performance issues with normal sort operations is because they use work_mem not maintenance_work_mem which was only set to 2048 anyway. Does that sound right? Regards, Gary.
