Re: More efficient RI checks - take 2

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: More efficient RI checks - take 2
Дата
Msg-id 20200422155556.j5svpnyvcyvhaa5w@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: More efficient RI checks - take 2  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Hi,

On 2020-04-21 16:14:53 -0400, Tom Lane wrote:
> AFAIK, we do not have any code besides the planner that is capable of
> building a plan tree at all, and I'd be pretty hesitant to try to create
> such; those things are complicated.

I suspect what was meant was not to create the plan tree directly, but
to bypass SPI when creating the plan / executing the query.


IMO SPI for most uses in core PG really adds more complication and
overhead than warranted.  The whole concept of having a global tuptable,
a stack and xact.c integration to repair that design defficiency... The
hiding of what happens behind a pretty random set of different
abstractions.  That all makes it appear as if SPI did something super
complicated, but it really doesn't. It just is a bad and
over-complicated abstraction layer.

Greetings,

Andres Freund



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: More efficient RI checks - take 2
Следующее
От: Juan José Santamaría Flecha
Дата:
Сообщение: Re: PG compilation error with Visual Studio 2015/2017/2019