On Thu, Mar 1, 2012 at 8:49 PM, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: > On 01.03.2012 18:40, Simon Riggs wrote: >> >> On Sun, Feb 26, 2012 at 7:16 PM, Heikki Linnakangas >> <heikki.linnakan...@enterprisedb.com> wrote: >>> >>> On 24.02.2012 22:55, Simon Riggs wrote: >>>> >>>> >>>> What exactly does it do? Previously, we optimised COPY when it was >>>> loading data into a newly created table or a freshly truncated table. >>>> This patch extends that and actually sets the tuple header flag as >>>> HEAP_XMIN_COMMITTED during the load. Doing so is simple 2 lines of >>>> code. The patch also adds some tests for corner cases that would make >>>> that action break MVCC - though those cases are minor and typical data >>>> loads will benefit fully from this. >>> >>> >>> This doesn't work with subtransactions: >> >> ... >>> >>> The query should return the row copied in the same subtransaction. >> >> >> Thanks for pointing that out. >> >> New patch with corrected logic and test case attached. > > > It's still broken:
Agreed. Thanks for your detailed input. Performance test results show that playing with XidInMVCCSnapshot() causes a small but growing performance regression that I find unacceptable, so while I might fix the above, I doubt if I can improve this as well. So this approach isn't the one... The COPY FREEZE patch provides a way for the user to say explicitly that they don't really care about these MVCC corner cases and as a result allows us to avoid touching XidInMVCCSnapshot() at all. So there is still a patch on the table. -- 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
