Take the 2-minute tour ×
Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It's 100% free, no registration required.

I have heavily updated / accessed table where I store serialized java objects. They are in the table for 2-3 hours (also are being updated during that period) and then removed. Size of table is around 300MB. I have spotted it is very, very often VACUUMed and wonder if changing the fillfactor would help?

share|improve this question
add comment

1 Answer

up vote 7 down vote accepted

The key words here are:

  1. "heavily updated"
  2. "in the table for 2-3 hours".

Point 1. is indication for a lower fill factor, while 2. is the opposite. It helps performance if multiple row versions are stored on the same data page. H.O.T. updates would achieve that. Read here or here. They need some wiggle room on the data page - like dead tuples or space reserved by a fillfactor < 100. But they can only do their thing, if no index involves any of the updated columns, which should be true for your case.

Another important factor here would be the tuple size (in comparison to your page size (which is most commonly 8 kb). More details in this related answer:
Measure the size of a PostgreSQL table row

If the tuple size is 4 kb or more, reducing the fill factor would be futile, since there can never be more than one tuple on a data page. You might as well leave it at 100 (which is the default anyway). Be aware, however, that some data types are "toasted" and stored out-of-line, so tuples requiring that much in the main table are rare.

Whatever you do, VACUUM will be run often. And that's generally a good thing. You create lots of dead tuples. I wouldn't worry about that. You can play with per-table settings for autovacuum to trigger it less often for this table only:

The default thresholds and scale factors are taken from postgresql.conf, but it is possible to override them on a table-by-table basis;

Bold emphasis mine. In particular with autovacuum_vacuum_threshold and autovacuum_vacuum_scale_factor. That might actually be a good idea, instead of a very low fillfacter. If you prevent VACUUM from running too often, you might have dead tuples on your data pages automatically, which can be re-used by HOT-updates.

But that depends on access patterns. If all tuples live, say, 3 hours and are inserted in chronological order, and each is updated several times, I would still lower the fillfactor to something like 50. You'll have to test and find the sweet spot.

Alternatives

All this aside, since your data seem to be volatile to begin with: use an UNLOGGED table:

Data written to unlogged tables is not written to the write-ahead log (see Chapter 29), which makes them considerably faster than ordinary tables. However, they are not crash-safe: an unlogged table is automatically truncated after a crash or unclean shutdown. The contents of an unlogged table are also not replicated to standby servers.

Bold emphasis mine. So, don't use this if your server might crash and you still need the data afterwards. But if we are talking about session data for web applications, this might be an acceptable price to pay.

Or, even more radical: Use a key-value store like Redis if you can do without the features and security provided by an RDBMS altogether.

share|improve this answer
    
I think UNLOGGED is exactly what I need –  Michal Mar 12 '13 at 7:40
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.