| From: | Greg Stark <stark(at)mit(dot)edu> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Craig Ringer <craig(at)2ndquadrant(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Postgres with pthread |
| Date: | 2017-12-07 20:48:06 |
| Message-ID: | CAM-w4HNPHfFwL+YaMCiKKqynrong8aHajnDNEr+zUbOJ-DhD1w@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 7 December 2017 at 19:58, Andres Freund <andres(at)anarazel(dot)de> wrote:
> On 2017-12-07 11:26:07 +0800, Craig Ringer wrote:
>> PostgreSQL's architecture conflates "connection", "session" and "executor"
>> into one somewhat muddled mess.
>
> How is the executor entangled in the other two?
I was going to ask the same question. AFAICS it's the one part of
Postgres that isn't muddled at all -- it's crystal clear that
"connection" == "session" as far as the backend is concerned and
"executor context" is completely separate.
But then I thought about it a bit and I do wonder. I don't know how
well we test having multiple portals doing all kinds of different
query plans with their execution interleaved. And I definitely have
doubts whether you can start SPI sessions from arbitrary points in the
executor expression evaluation and don't know what state you can leave
and resume them from on subsequent evaluations...
--
greg
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2017-12-07 20:52:51 | Re: Postgres with pthread |
| Previous Message | Andres Freund | 2017-12-07 20:46:22 | Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple |