> 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 

> 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 

Best regards

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to