> > If that 1% is random (not time/transaction related), usually you'd rather
>have an empty table.
>
> Why do you think it would be random?
"Heap blocks would be zeroed if they were found to be damaged, following a
crash."
If you erase full blocks, you have no idea what data you erased; it could be
something changed 1 hour ago, 1 month ago, 1 year ago. This is very different
from,
say, synchronous_commit=off: in that case, "the most recent transactions may be
lost if the database should crash". In your case, "some (who knows which???)
data
is lost". So, to me that sounds like random loss. I don't think that that is
different
from a corrupted table. You're not deleting rows recently changed; you're
deleting
everything that is "physically close" to it.
> > In other words: is a table that is not consistant with anything else in the
>db useful?
>
> That's too big a leap. Why would it suddenly be inconsistent with the
> rest of the database?
If you delete some data, and you have no idea what data you lost, I don't think
you have a
consistent db. Unless, of course, your table has no relation with any other
table in the db.
Of course, all these thoughts are based on the assumption that I know what
happens when a
block is erased; but my knowledge of postgresql internals is not so good, so I
might be
*very* wrong
