Enabling "Auto create statistics" / "Auto update statistics" at the tempdb databas

Should I enable the "Auto create statistics" and "Auto update statistics" parameters at the tempdb database? I've heard that it's necessary to increase tempdb performance. Could you confirm if it's true?
Thanks in advance.
VagnerStatistics is very important for performance. SQL Server uses this info when
it decides whther to use an index or not. You should have the auto
parameters set to on in all databases. Well, if you are not using tempdb a
lot, then it is not so important for tempdb, but I would set them on anyway.
--
Dejan Sarka, SQL Server MVP
Please reply only to the newsgroups.
"Vagner Cuccino" <anonymous@.discussions.microsoft.com> wrote in message
news:A324064F-3E90-4E6D-B851-3AE1B3F7825A@.microsoft.com...
> Should I enable the "Auto create statistics" and "Auto update statistics"
parameters at the tempdb database? I've heard that it's necessary to
increase tempdb performance. Could you confirm if it's true?
> Thanks in advance.
>
> Vagner
>|||"Dejan Sarka" <dejan_please_reply_to_newsgroups.sarka@.avtenta.si> wrote in
message news:OJjT2l%23vDHA.2304@.TK2MSFTNGP12.phx.gbl...
> Statistics is very important for performance. SQL Server uses this info
when
> it decides whther to use an index or not. You should have the auto
> parameters set to on in all databases. Well, if you are not using tempdb a
> lot, then it is not so important for tempdb, but I would set them on
anyway.
I would agree with you for new systems. For older systems previously based
and tweaked on earlier SQL Server versions like 6.5, especially real time
OLTP apps, I would suggest not unless you're in a position to open the code
up and re-tweak the app.
In general, auto create and update statistics will make older tweaked apps
run worse than before!
But bear in mind for both new and legacy applications, the serious
consideration that auto create and update stats don't do full scans, which
for anything more than fairly trivial amounts of data can be a significant
performance problem. The optimiser may choose a non-optimum execution plan
as it is basing its decision on a potentially non-representative sample of
data. You need to understand your data's distribution and cardinality to
make a call on this. In addition often there is some mutuality between
distinct column values in a table, for example if you have status flags or
values. In these cases it is often well worth manually creating composite
statistics to help the optimiser understand this.
Kind Regards, Howard