da...@lang.hm writes:
the poster who started this thread had a query where the parsing phase
took significantly longer than the planning stage.
That was an anecdote utterly unsupported by evidence.
regards, tom lane
The issue of prepared statements having atrocious
On Wed, Dec 31, 2008 at 11:01 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
The point of a prepared statement IMHO is to do the planning only once.
There's necessarily a tradeoff between that and having a plan that's
perfectly adapted to specific parameter values.
I think it has been
On Wed, Dec 31, 2008 at 5:01 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
I think it has been shown enough times that the performance drop caused
by a worse plan can be orders of magnitudes worse than what's gained by
producing the plan only once. It does not seem a bad idea to provide
On Thu, 1 Jan 2009, Guillaume Smet wrote:
On Wed, Dec 31, 2008 at 5:01 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
I think it has been shown enough times that the performance drop caused
by a worse plan can be orders of magnitudes worse than what's gained by
producing the plan only
On Thu, Jan 1, 2009 at 9:24 PM, da...@lang.hm wrote:
forgive my ignorance here, but if it's unnamed how can you reference it
later to take advantage of the parsing?
You can't. That's what unnamed prepared statements are for.
It's not obvious to me that the parsing phase is worth any caching.
On Thu, 1 Jan 2009, Guillaume Smet wrote:
On Thu, Jan 1, 2009 at 9:24 PM, da...@lang.hm wrote:
forgive my ignorance here, but if it's unnamed how can you reference it
later to take advantage of the parsing?
You can't. That's what unnamed prepared statements are for.
It's not obvious to me
da...@lang.hm writes:
the poster who started this thread had a query where the parsing phase
took significantly longer than the planning stage.
That was an anecdote utterly unsupported by evidence.
regards, tom lane
--
Sent via pgsql-performance mailing list
On Tue, Dec 30, 2008 at 7:59 PM, bricklen brick...@gmail.com wrote:
I would like to continue to use bind variables to prevent sql
injection, but I'd like to force a plan re-parse for every single
query (if necessary?)
As far as I understand your problem, you don't care about using
prepared
Hi Guillaume,
On Wed, Dec 31, 2008 at 1:12 AM, Guillaume Smet
guillaume.s...@gmail.com wrote:
On Tue, Dec 30, 2008 at 7:59 PM, bricklen brick...@gmail.com wrote:
I would like to continue to use bind variables to prevent sql
injection, but I'd like to force a plan re-parse for every single
Tom Lane escribió:
Scott Carey sc...@richrelevance.com writes:
I have also had a case where one query would take a couple hundred
ms to parse, but was fairly fast to plan and execute (1/3 the parse
cost) -- yet another case where a prepared statement that re-plans
each execution would be
Hi, I am re-posting my question here after trying to find a solution
in the PHP pgsql list with no luck.
I am experiencing some performance issues that I think are stemming
from prepared statements. I have a pretty simple query:
SELECT cl.idOffer,cl.idaffiliate ,cl.subid,cl.datetime
FROM click
On Tue, Dec 30, 2008 at 1:59 PM, bricklen brick...@gmail.com wrote:
Hi, I am re-posting my question here after trying to find a solution
in the PHP pgsql list with no luck.
I am experiencing some performance issues that I think are stemming
from prepared statements. I have a pretty simple
Hi Merlin,
On Tue, Dec 30, 2008 at 11:42 AM, Merlin Moncure mmonc...@gmail.com wrote:
On Tue, Dec 30, 2008 at 1:59 PM, bricklen brick...@gmail.com wrote:
Hi, I am re-posting my question here after trying to find a solution
in the PHP pgsql list with no luck.
I am experiencing some
On Tue, Dec 30, 2008 at 12:42 PM, Merlin Moncure mmonc...@gmail.com wrote:
On Tue, Dec 30, 2008 at 1:59 PM, bricklen brick...@gmail.com wrote:
Hi, I am re-posting my question here after trying to find a solution
in the PHP pgsql list with no luck.
I am experiencing some performance issues
Hi Scott,
On Tue, Dec 30, 2008 at 12:09 PM, Scott Marlowe scott.marl...@gmail.com wrote:
On Tue, Dec 30, 2008 at 12:42 PM, Merlin Moncure mmonc...@gmail.com wrote:
On Tue, Dec 30, 2008 at 1:59 PM, bricklen brick...@gmail.com wrote:
Hi, I am re-posting my question here after trying to find a
.
From: pgsql-performance-ow...@postgresql.org
[pgsql-performance-ow...@postgresql.org] On Behalf Of bricklen
[brick...@gmail.com]
Sent: Tuesday, December 30, 2008 12:14 PM
To: Scott Marlowe
Cc: Merlin Moncure; pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Poor plan choice in prepared
On Tue, Dec 30, 2008 at 1:09 PM, Scott Carey sc...@richrelevance.com wrote:
There is no way to force Postgres to re-plan a prepared statement. In many
cases, this would be a hugely beneficial feature (perhaps part of the
definition of the statement?).
I have had similar issues, and had to
Scott Carey sc...@richrelevance.com writes:
I have also had a case where one query would take a couple hundred ms to
parse, but was fairly fast to plan and execute (1/3 the parse cost) -- yet
another case where a prepared statement that re-plans each execution would be
helpful. At least
Hi Tom,
On Tue, Dec 30, 2008 at 3:02 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The point of a prepared statement IMHO is to do the planning only once.
There's necessarily a tradeoff between that and having a plan that's
perfectly adapted to specific parameter values.
I agree, and normally it
On Tue, 30 Dec 2008, Tom Lane wrote:
Scott Carey sc...@richrelevance.com writes:
I have also had a case where one query would take a couple hundred ms to
parse, but was fairly fast to plan and execute (1/3 the parse cost) -- yet
another case where a prepared statement that re-plans each
da...@lang.hm writes:
since there is not a pre-parsed interface for queries, it may make sense to
setup a way to have the query pre-parsed, but not pre-planned for cases like
this.
What would be more interesting would be to have plans that take into account
the outlier values and have
21 matches
Mail list logo
