Thanks for your feedback. Actually when I said that the same overhead occurs in Oracle I was referring to bloat in the UNDO logs, which similar to PostgreSQL dead tuples has some impact on size/performance and is the majority of the trade-off considered when deciding to implement Flashback.
In terms of benefit over a lagging replica Flashback has the benefit of being transparent to the user (the user can query over the same database connection, etc), it does not incur the full cost of having a replica...
William Dunn wrote: > Just had an idea and could use some feedback. If we start a transaction, leave it idle, and use > pg_export_snapshot() to get its snapshot_id MVCC will hold all the tuples as of that transaction's > start and any other transaction can see the state of the database as of that time using SET > TRANSACTION SNAPSHOT snapshot_id? > > http://www.postgresql.org/docs/devel/static/functions-admin.html#FUNCTIONS-SNAPSHOT-SYNCHRONIZATION > > > I'm thinking of setting up automation to ~every half hour open a transaction as such, close any that > have been open over an hour, and store the snapshot_id. However, I don't have a busy system that I can > test it on. > > Of course this would cause some extra bloat because those tuples cannot get autovacuumed until the > transaction closes but that is also the case in Oracle. Is there anything else I am missing or a > reason that this would not be possible?
Oracle does not have that issue because modifications cannot bloat the table (the bloat is in what is called the "UNDO tablespace").
What you suggest would allow you to look at the data as they were at specific times (of the snapshots). But the price on a busy system where data are modified would be considerable; your tables might become quite bloated, and you could not use HOT updates.
If you want to look into the past, wouldn't it be much more useful to have a standby server that is lagging behind? There is an option for that (recovery_min_apply_delay) from PostgreSQL 9.4 on.
