Archives of the TeradataForum
Message Posted: Tue, 17 Nov 2009 @ 14:53:25 GMT
I just watched a very large (multi-hundred-million row) global-temp table being redistributed to all AMPs because the optimizer estimated it would contain 3,000 rows.
The query involved was a fairly simple update. It *should* have just taken a few minutes to execute, rather than creating a massive I/O problem on the system for many hours.
I have a future enhancement suggestion to make:
I think there should be some sort of mechanism that allows the AMPS to report such a large difference (3K versus 417M) in the expected-versus- actual size of a spool file back to the optimizer. That would give it a chance to re-evaluate the execution plan and generate new estimates given that new data. Hopefully it could then "re-think" the balance of the steps in the plan - which calls for that larger than expected spool file to be sorted, duplicated or redistributed to all AMPS, and used in a product join (more than once) in later steps.
|Copyright 2016 - All Rights Reserved|
|Last Modified: 23 Jun 2019|