Archives of the TeradataForum

Message Posted: Wed, 02 Jan 2002 @ 19:04:18 GMT

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

NOTE: Due to admin issues w/ my forum membership, a previous copy of this note went out as anonymous. That wasn't my intent.

I'm looking for any practical feedback on this topic. I don't need any proselytizing on Teradata's widely respected optimizer.

In a world of increasingly complex SQL and BI tool query generators, a means for DBAs and developers to give clues or suggestions to the optimizer seems more valuable than ever. The optimizer is not infallible. Production sites need a way to deal with those occasions when the optimizer misfires (the process is for any such sub-optimization to be reported to NCR to identify opportunities for improvement). The real world is getting too complicated for the optimizer to be right every time on every release with every new feature. The optimizer might accept clues/suggestions as simply that - recommendations for building a plan -- perhaps the optimizer could generate two plans (with and without the suggestion) and choose the cheaper plan. With changing demographics, such clues will grow stale, so perhaps time stamp them.

An alternative to giving clues is workarounds such as fudging statistics to influence the optimizer. (not with the backdoor value statement) In the real need-it-now world, Teradata application developers and DBAs need a means of influencing the optimizer without cumbersome workarounds such as inserting dummy rows, collecting stats, deleting the rows and then loading the real data. A workaround like that takes time to document, is impossible to recognize if not documented, and is a land mine for any follow-on developer. A hint would be nearer to self-documenting (at least it is recognizable) and safer to deal with.

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