Re: 15x slower PreparedStatement vs raw query

2021-05-04 Thread Justin Pryzby
On Mon, May 03, 2021 at 03:18:11PM -0500, Justin Pryzby wrote: > On Sun, May 02, 2021 at 07:45:26PM +, Alex wrote: > > PreparedStatement: 15s > > Raw query with embedded params: 1s > > See issue on github with query and explain analyze: > > https://github.com/pgjdbc/pgjdbc/issues/2145 > > | ..

Re: 15x slower PreparedStatement vs raw query

2021-05-04 Thread David Rowley
On Tue, 4 May 2021 at 22:05, Alex wrote: > Shouldn't this process be automatic based on some heuristics? When plan_cache_mode is set to "auto", then the decision to use a generic or custom plan is cost-based. See [1]. There's a fairly crude method there for estimating the effort required to repla

Re: 15x slower PreparedStatement vs raw query

2021-05-04 Thread Vijaykumar Jain
I am not an expert on this, But I would like to take a shot :) Is it possible to share your prepared statement and parameter types. I mean something like this PREPARE usrrptplan (int) AS SELECT * FROM users u, logs l WHERE u.usrid=$1 AND u.usrid=l.usrid AND l.date = $2; EXECUTE usrrptpla

Re: 15x slower PreparedStatement vs raw query

2021-05-04 Thread Laurenz Albe
On Tue, 2021-05-04 at 13:59 +, Alex wrote: > "Powerful general purpose relational database" but not smart... Too smart can easily become slow... > I propose a feature to use information from previously executed queries to > adjust the query plan time accordingly. > Reusing the same generic

Re: 15x slower PreparedStatement vs raw query

2021-05-04 Thread Alex
"Powerful general purpose relational database" but not smart... I propose a feature to use information from previously executed queries to adjust the query plan time accordingly. Reusing the same generic plan may and will lead to very long execution times. Rick Otten wrote: On Tue, May 4, 2021 at

Re: 15x slower PreparedStatement vs raw query

2021-05-04 Thread Rick Otten
On Tue, May 4, 2021 at 6:05 AM Alex wrote: > Shouldn't this process be automatic based on some heuristics? > > Saving 10ms planning but costing 14s execution is catastrophic. > > For example, using some statistics to limit planner time to some percent > of of previous executions. > This way, if q

Re: 15x slower PreparedStatement vs raw query

2021-05-04 Thread Alex
Shouldn't this process be automatic based on some heuristics? Saving 10ms planning but costing 14s execution is catastrophic. For example, using some statistics to limit planner time to some percent of of previous executions. This way, if query is fast, planning is fast, but if query is slow, more