Tim Uckun wrote
> The database is functioning fine now but I am anticipating a much higher
> workload in the future. The table in question is probably going to have a
> few million rows per day inserted into it when it gets busy, if it gets
> very busy it might be in the tens of millions per day but that's
> speculation at this point.
>
> I don't want to say that the data is not important but if I drop one or
> two
> sensor readings it's not going to be the end of the world.
If the server crashes immediately before, or even during, the movement
process you are going to lose every record - apparently in the order of
tens-of-thousands - on the unlogged table.
I am not certain that your stated fear/goal is relevant:
"I was thinking about keeping the high churn data in a different table so
that the vacuums on that table can go faster and the vacuums on the rest of
the data will rarely be needed."
http://www.postgresql.org/docs/9.2/interactive/routine-vacuuming.html#VACUUM-BASICS
Section 23.1.4 Updating the Visibility Map
In terms of caching, both indexes and data are placed into memory on a page
basis; anything that is not in use will remain dormant. There will be some
impact but whether it is enough to add in the complexity of partitions
and/or archive tables is use-specific. The ability to move those tables to
other tablespaces is solid as is the ability to simply drop the partition to
remove said data from the database - but neither ability is useful in all
situations.
--
View this message in context: http://postgresql.1045698.n5.nabble.com/Fast-data-slow-data-tp5809324p5809551.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.
