On Thu, Mar 1, 2012 at 8:49 PM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> On 01.03.2012 18:40, Simon Riggs wrote:
>>
>> On Sun, Feb 26, 2012 at 7:16 PM, Heikki Linnakangas
>> <heikki.linnakangas@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
