Re: RFC: Making TRUNCATE more "MVCC-safe"

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: RFC: Making TRUNCATE more "MVCC-safe"
Дата
Msg-id CA+U5nMJ4Srx6i3HUqODB3hPr0a6nVAHHsFrmgnpg12bkBiEHLQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: RFC: Making TRUNCATE more "MVCC-safe"  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: RFC: Making TRUNCATE more "MVCC-safe"
Список pgsql-hackers
On Wed, Mar 7, 2012 at 5:39 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Wed, Mar 7, 2012 at 10:26 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> On Wed, Mar 7, 2012 at 2:59 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>>> All true.
>>
>> So gentlemen, do we think this is worth pursuing further for this release?
>>
>> I'm sure usual arguments apply all round, so I'll skip that part.
>
> This patch is awfully late to the party, but if we can nail it down
> reasonably quickly I guess I'd be in favor of slipping something in.

Cool

> I am not thrilled with the design as it stands, but bulk loading is a
> known and serious pain point for us, so it would be awfully nice to
> improve it.  I'm not sure whether we should only go as far as setting
> HEAP_XMIN_COMMITTED or whether we should actually try to mark the
> tuples with FrozenXID.  The former has the advantage of (I think) not
> requiring any other changes to preserve MVCC semantics while the
> latter is, obviously, a bigger performance improvement.

It's the other way around. Setting to FrozenTransactionId makes the
test in XidInMVCCSnapshot() pass when accessed by later commands in
the same transaction. If we just set the hint we need to play around
to get it accepted. So the frozen route is both best for performance
and least impact on fastpath visibility code. That part of the code is
solid.

The only problem is the visibility from older snapshots, we just
need/desire a better place to put the test. So I'll finish that off.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: poll: CHECK TRIGGER?
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: poll: CHECK TRIGGER?