When/if to Reindex

We're using Postgres 8.2.4.

I'm trying to decide whether it's worthwhile to implement a process that
does periodic reindexing. In a few ad hoc tests, where I've tried to set up
data similar to how our application does it, I've noticed decent performance
increases after doing a reindex as well as the planner being more likely to
choose an index scan.

Some background: we make extensive use of partitioned tables. In fact, I'm
really only considering reindexing partitions that have "just closed". In
our simplest/most general case, we have a table partitioned by a timestamp
column, each partition 24 hours wide. The partition will have an index on
the timestamp column as well as a few other indexes including a primary key
index (all b-tree). Is there a programmatic way I can decide, upon the
"closing" of a partition, which, if any, of these indexes will benefit from
a reindex? Can I determine things like average node density, node depth, or
any other indication as to the quality of an index? Will pg_class.relpages
be any help here?

Is it a simple matter of running some queries, reindexing the table, then
running the queries again to determine overall performance change? If so,
what queries would exercise this best?

Just trying to determine if the extra cost of reindexing newly closed
partitions will be worth the performance benefit of querying the data.
Reindexing a table with a day's worth of data is taking on the order of a
few hours (10s of millions of rows).

The docs say that:

"...for B-tree indexes a freshly-constructed index is somewhat faster to
access than one that has been updated many times, because logically adjacent
pages are usually also physically adjacent in a newly built index... It
might be worthwhile to reindex periodically just to improve access speed."

Thanks,
Steve