Designing DB partitions you don't have to babysit

This is a topic that interests me a lot but there's a lot I find surprising since I finally started working with postgres dependent apps. Why for example is the id a good primary key? Joins are not uncommon, but I don't have anyone searching on id in my application and it is not even supposed to be user visible. I would think every possible user search would look at all partitions indexes if I did this instead of creation date.

[dead]

[dead]

Or just use kdb+ and 1bn rows a day is par for the course.