On 12/30/2015 08:16 AM, David Rowley wrote:
I do strongly believe that we need to come up with something to solve this problem. I already summarised my thoughts on the other thread.
One approach that I don't see mentioned on any of the threads is plan caching, which allows reusing the plan across many query executions, hopefully amortizing the planning costs.
I'm sure implementing such caching is non-trivial and there are cases where it may not help, but perhaps it's not entirely futile (AFAIK it's used by some databases exactly to address the higher planning costs).
I imagine a single GUC enabling or disabling this (possibly not just globally but per session, user or database).
We already have some form of plan caching, although only for prepared statements within a single session - maybe that could be a good starting point? For example what if we only enabled those "expensive" optimizations for prepared statements, which are assumed to be executed multiple times? Of course, this may not be entirely true (say, PL/pgSQL uses prepared statements all the time).
Of course, the annoying consequence of this would be that the planning may get somewhat unpredictable - the plan will depend on whether the query was planned directly or as a prepared statement, or whether plan caching is enabled. However, the same mostly applies to solutions proposed in the other threads so far.
regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
