On 14/09/14 20:43, Mark Kirkwood wrote:
On 14/09/14 20:24, Atri Sharma wrote:
How do you plan to do all that VACUUM does for this table then?
It seems to me that you are saying to VACUUM that it need not be
concerned with table 'A' and you are assuming ownership of all the tasks
performed by VACUUM for this table. Seems pretty broken to me, not to
mention the performance degradations.
I think the whole point of such a modification is that nothing is done
to such tables, as you want to see all the previous versions.
Clearly this is less performant for standard workloads...but we are
talking about non standard workloads surely...
To be fair with respect to what Atri is saying, I should have said
something like:
Clearly this is *horribly* less performant for standard workloads...etc :-)
Also there is the good point he raised about transaction xid wrap, so
some messing about with that part of VACUUM would be required too (it's
the little complications that all add up)!
The TRIGGER based approach is clearly a lot simpler! However for an
interest project to understand Postgres internals the other approach is
worthwhile.
Cheers
Mark
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
