> 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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers