Re: Parallel execution and prepared statements

From: Tobias Bussmann <t(dot)bussmann(at)gmx(dot)net>
To: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Subject: Re: Parallel execution and prepared statements
Date: 2016-11-21 15:11:51
Message-ID: 163C934C-6492-4823-82DB-1EBFB7E3E610@gmx.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> True, but we also try to avoid it whenever possible, because it's
> likely to lead to poor performance.

This non-readonly case should be way less often hit compared to other uses of prepared statements. But sure, it depends on the individual use case and a likely performance regession in these edge cases is nothing to decide for easily.

> I think it would be a good idea to come up with a way for a query to
> produce both a parallel and a non-parallel plan and pick between them
> at execution time. However, that's more work than I've been willing
> to undertake.

Wouldn't the precautionary generation of two plans always increase the planning overhead, which precisely is what one want to reduce by using prepared statements?

Best regards
Tobias

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2016-11-21 15:15:33 Re: condition variables
Previous Message Vladimir Svedov 2016-11-21 14:32:20 postgres 9.3 postgres_fdw ::LOG: could not receive data from client: Connection reset by peer