Does a messy table definition repository affect performance?

[SBSA_DW2]

Hi

Is there a relationship between the number fo table definitions in the repository and the impact on performance of the jobs?

I can think that the repository which stores everything will be impacted and that at a minimum job start-up time will be impacted, but will the runtime of a job be impacted?

I'm trying to motivate for a cleaner table definition space. I'm sure everyone will agree that the following is useless:
Category: Saved
Data Source: Aaaaa
Table Definition: _aaaaaaaaaa

[chulett]

No, there's no impact on the performance of the jobs that I've ever seen. The performance of the job coder, perhaps, but not the jobs themselves.

[ArndW]

Although I concur with Craig, I can imagine a scenario when logging to the repository at 8.1 and beyond and the repository is full of both log files and table definitions that it might impact runtime performance, particularly if a lot of records get written to the job log.

[chulett]

OK, sure, anything that makes either the Universe or XMETA repositories full would be a Bad Thing.

[SBSA_DW2]

thanks for the responses - i'll feedback to the team.