It depends entirely on what kind of LC you're using. Much older LC's like the M1 and M2 can run sampled or un-sampled but there are limits to how many packets per second the processors on the LC and supervisor can track and generate. The newer blades (F2/F2e/M3 and presumably F4) have to run sampling and have minimum limits (i.e. no more than 1 in 100 or so) as well as being limited to a certain number of packets per second. In turn, the system has limits in terms of the total number of flows kept in memory at a given time as well as how many exports can be put on the wire per second.
The line cards (..or the various ASIC's on line cards) can generate flow entries up to a certain number of packets per second. These flows are sent over the EOBC to the system's cache on the CPU. The rate at which those collectors generate flows dictates how quickly that that flow cache fills up. A few gigantic long-lived flows uses a tiny amount of memory. Relatively low bandwidth filled with packets from constantly varying sources and destinations can blow the cache out surprisingly quickly. There's a maximum rate at which the CPU can generate flow exports on the wire, but within that the rate of flows being generated is a function of both the table's size and the average lifespan of the flows. Again - a box that's pegged with long-lived elephant flows won't tax either the cache or the CPU, while traffic generated with random sources and destinations can max the entire thing out surprisingly quickly. Sampling attempts to address these issues (the rate at which traffic is analyzed and the number of flows the CPU sees and exports).
So would 1 out of 1000 be adequate with that traffic flow? It's hard to say without knowing the nature of the traffic and the line cards in use. If you're distributed across SoC complexes on F3's? Almost certainly fine. If it's all on a single F2 blade? Probably not.
Cisco's documentation gets into the specific detail for the various LC's and system limits. I'd suggest using that as a starting point.
