Re: Calculate hardware needs based on desired writes per second

[Rick James]

Glad to hear things are getting better.

> Then there is a second table, historical_offers, that contains only a price and availability history for each day and offer in the other table. After Aftab's suggestions, I stripped that table of all but one index and made (offer_id, valid_at) the primary index.
> I could certainly partition historical_offers by valid_at, i.e. the 90-92 days (3 months), if you suggest it helps?

Let's focus on the details -- please provide the tentative schema and the queries that would be hitting it. Keep in mind that partitioning, by itself, does not help anything. Only certain queries benefit from the split.

> a second query load all matching historical_offer
That sounds like reading the whole table?? (Partitioning would not help that.)

Which is more important (performance-wise)? Loading a new set of offers? Or fetching the history? The answer will help determine what the PRIMARY KEY should be, and what (if anything) you should partition on.

How many rows in the offers table (eventually)?