| From: | Tobias Bussmann <t(dot)bussmann(at)gmx(dot)net> |
|---|---|
| To: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Cc: | Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com> |
| Subject: | Re: Parallel execution and prepared statements |
| Date: | 2016-11-17 15:07:00 |
| Message-ID: | 95EE0F03-0341-41F0-891C-19631C2B6E24@gmx.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> Yeah, we could do something like this, perhaps not in exactly this
> way, but I'm not sure it's a good idea to just execute the parallel
> plan without workers.
sure, executing parallel plans w/o workers seems a bit of a hack. But:
- we already do it this way in some other situations
- the alternative in this special situation would be to _force_ replanning without the CURSOR_OPT_PARALLEL_OK. The decision for replanning is hidden deep within plancache.c and while we could influence it with CURSOR_OPT_CUSTOM_PLAN this wouldn't have an effect if the prepared statement doesn't have any parameters. Additionally, influencing the decision and generating a non-parallel plan would shift the avg cost calculation used to choose custom or generic plans.
Maybe someone can come up with a better idea for a solution. These three approaches are all I see so far.
Best regards,
Tobias Bussmann
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2016-11-17 15:29:35 | Re: Assignment of valid collation for SET operations on queries with UNKNOWN types. |
| Previous Message | Robert Haas | 2016-11-17 15:06:28 | Re: Unlogged tables cleanup |