Re: Table AM Interface Enhancements

Поиск
Список
Период
Сортировка
От Alexander Korotkov
Тема Re: Table AM Interface Enhancements
Дата
Msg-id CAPpHfdsmziv-+B3_7Va4ydkL9E-vh4RZF9qRR1oQiSqLHB4qpA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Table AM Interface Enhancements  (Pavel Borisov <pashkin.elfe@gmail.com>)
Ответы Re: Table AM Interface Enhancements  (Andrei Lepikhov <a.lepikhov@postgrespro.ru>)
Re: Table AM Interface Enhancements  (Jeff Davis <pgsql@j-davis.com>)
Re: Table AM Interface Enhancements  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
Hi, Pavel!

I've pushed 0001, 0002 and 0006.

On Fri, Mar 29, 2024 at 5:23 PM Pavel Borisov <pashkin.elfe@gmail.com> wrote:
>>
>> I think for better code look this could be removed:
>> >vlock:
>>  >                       CHECK_FOR_INTERRUPTS();
>> together with CHECK_FOR_INTERRUPTS(); in heapam_tuple_insert_with_arbiter placed in the beginning of while loop.
>
> To clarify things, this I wrote only about CHECK_FOR_INTERRUPTS(); rearrangement.

Thank you for your review of this patch.  But I still think there is a
problem that this patch moves part of the executor to table AM which
directly uses executor data structures and functions.  This works, but
not committable since it breaks the encapsulation.

I think the way forward might be to introduce the new API, which would
isolate executor details from table AM.  We may introduce a new data
structure InsertWithArbiterContext which would contain EState and a
set of callbacks which would avoid table AM from calling the executor
directly.  That should be our goal for pg18.  Now, this is too close
to FF to design a new API.

------
Regards,
Alexander Korotkov



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

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~?
Следующее
От: Corey Huinker
Дата:
Сообщение: Re: Statistics Import and Export