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 по дате отправления: