Archives of the TeradataForum

Message Posted: Thu, 30 May 2002 @ 14:25:49 GMT

	<Prev	Next>		<<First	<Prev	Next>	Last>>

Maybe I'm feeling grumpy today, but claiming 'maximum functionality' with 'minimal overhead' waved a red flag in my direction.

The PREPINFO (or PREPARE) parcel provides information about the metrics of a query and its answer set. To get those metrics, the PE (Parsing Engine) needs to develop the workplan for the query - effectively it's an EXPLAIN.

For those not familiar with it, the PREPINFO parcel contains information like:

CostEstimate (or estimated run time)
SummaryCount (number of WITH clauses)
ColumnCount (number of columns being returned)
DataType for returned columns
DataLen for returned columns
ColumnName for returned columns
ColumnFormat for returned columns
ColumnTitle for returned columns

So each time a PREPINFO (or more commonly an EXPLAIN) is executed, the Teradata accrues PE overhead. Probably not a terribly big issue, unless you have a busy machine where you don't want to waste any of the Teradata resources.

So to get to my point: Instead of having a configuration flag for SAS that can be set to indicate the release of the Teradata software (which only has to be dealt with once), somebody decided that it's more efficient to submit a spurious query with each actual query to determine if a feature is supported? I don't think so.

In that same vein, accruing a lot of PE overhead to see whether the relevant tables exist before submitting the actual query seems an equal waste of resources. The Teradata will give an error if a table isn't found - it's pretty sophisticated that way.

	<Prev	Next>		<<First	<Prev	Next>	Last>>