| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Greg Stark <stark(at)mit(dot)edu> |
| 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:52:51 |
| Message-ID: | 20171207205251.pq7epziihz2jlikk@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2017-12-07 20:48:06 +0000, Greg Stark wrote:
> 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.
Cursors test that pretty well.
> 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...
SPI being weird doesn't really have that much bearing on the executor
structure imo. But I'm unclear what you'd use SPI for that really
necessitates that. We don't suspend execution it the middle of function
execution...
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Munro | 2017-12-07 21:00:12 | Re: explain analyze output with parallel workers - question about meaning of information for explain.depesz.com |
| Previous Message | Greg Stark | 2017-12-07 20:48:06 | Re: Postgres with pthread |