I suppose they take up some space and therefore cause more I/O when the
table is queried (or written to for that matter). But, assuming the
fields aren't a significantly large portion of the row-size I'd guess
that the performance impact would be negligable?

Still, timestamp is quite a "large" datatype in the scheme of things
(10 bytes storage if I recall correctly?)

There's also the issue of whether you're using triggers to maintain the
timestamps on update, which I guess would add a bit to the processing
overhead of updates.

I guess it boils down to: if you don't actually *need* them on every
table, why have them? If you actually have a requirement to track the
created and modification dates (auditing and what-not), then you don't
have much of a choice, but if there's no such requirement I'd opt for
simplicity over complexity :-)

Dave.

Unless you have an extremely high insert rate, I would not worry about it.