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.
