Archives of the TeradataForum
Message Posted: Fri, 09 Jan 2004 @ 16:19:13 GMT
| Subj: || || Re: Explain Text - Synchronized Scanning |
| From: || || Fred W Pluebell |
In general you want the cache to hold blocks from small, commonly referenced tables.
| ||"The input table will not be cached in memory, ...|| |
Teradata will not use the basic "Least Recently Used" cache algorithm when scanning this table, because it is large enough that doing so would
likely flush out many other blocks that are more likely to be re-used.
| ||..., but is eligible for synchronized scanning"|| |
SyncScan allows a scan request to join an equivalent scan of the same table "already in progress". Some amount of cache space is used to hold
blocks temporarily in case another scan can use them. As long as the requests are processing rows at roughly the same rate, the physical I/O is
only done once. When the first scan finishes, the next will "wrap back" and read whatever part of the table it missed, and so forth.
| ||b) "The result spool file will not be cached in memory"|| |
Since Teradata knows the spool file contents are going to be used in at least one later step, it would improve performance to keep the data in
cache. But because the spool file is only going to be used by this one request, it is worth caching only if it is very small.