Closing out my recent round of Teradata-related posts, here’s a little anomaly:
- Teradata is proud that Teradata 14’s workload management now explicitly manages I/O, to go with Teradata’s long-standing management of CPU. Teradata’s WLM still does not explicitly manage RAM.
- Aster is proud that Aster 5’s workload management now explicitly manages RAM, to go along with the WLM capabilities Aster has had for a while managing CPU and I/O. Aster’s Tasso Argyros believes this is an important capability, at least in some edge cases.
- Mike Pilcher of SAND emailed me that SAND’s WLM capabilities to explicitly manage CPU, I/O, and RAM are very well-received by the marketplace.
One would think that Teradata’s workload management is more sophisticated and powerful than Aster Data’s.* So I asked Scott Gnau what gives (he was pretty much the ideal guy to comment, since he runs development for Teradata and oversees Teradata’s Aster acquisition as well).
*Except, of course, that Aster was a pioneer in having workload management cover all kinds of analytic processes, rather than just traditional database requests.
Scott’s main response was that Aster’s system was much more consumptive of RAM than Teradata’s; indeed, he reminded me that in the very old days, Teradata could make do with as little as 4 megabytes. Scott also did not argue when I suggested that Aster’s not-just-database analytic processes might require large amounts of RAM as well.