Unlogged tables are a good new feature. I noticed Bruce had mentioned they were the equivalent of NoSQL, which I don't really accept. I guess it depends upon whether you mean NoSQL for caches (e.g. memcached) or NoSQL for useful datastores (e.g. Mongo). It seems worth discussin now before we get too far into the marketing hype around Beta.
If you don't log changes to tables you have two choices if we crash 1) truncate the table and any indexes 2) rebuild any indexes damaged by the crash Currently, we do (1). That certainly has its place but most data stores don't do this if they crash, since it would lead to data loss. Not just a couple of rows either - serious, major data loss if you put the wrong kind of data in it. We even delete data that has been safely on disk for weeks, months, which IMHO some people could easily get confused about. In the future, I would like to work on (2), which preserves as much data as possible, while recognising indexes may be damaged. I don't really have any name for this, since the current naming seems to assume there is only one kind of unlogged table. My implementation path for that would be to add a crash_number onto pg_control and pg_index. Any index marked as "unlogged, persistent" would only be usable if it's crash number is the same as current system crash number. REINDEX would update the index crash number to current value. That also allows us to imagine a "repair index" command in the future as well. Heap blocks would be zeroed if they were found to be damaged, following a crash. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
