| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, Antonin Houska <ah(at)cybertec(dot)at>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: More efficient RI checks - take 2 |
| Date: | 2020-04-22 15:55:56 |
| Message-ID: | 20200422155556.j5svpnyvcyvhaa5w@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Juan José Santamaría Flecha | 2020-04-22 15:56:42 | Re: PG compilation error with Visual Studio 2015/2017/2019 |
| Previous Message | Andres Freund | 2020-04-22 15:42:31 | Re: More efficient RI checks - take 2 |