On Thu, Aug 12, 2010 at 11:15 AM, Tom Lane wrote:
>> I'm not exactly following this. My guess is that the breakeven point
>> is going to be pretty low because I think Param nodes are pretty
>> cheap.
>
> If you have any significant number of executions of the expression, then
> of course converti
Robert Haas writes:
> On Thu, Aug 12, 2010 at 10:44 AM, Tom Lane wrote:
>> Well, I was thinking in terms of doing it when we do the SRF inlining.
>> It might be that we could get away with just having an arbitrary cost
>> limit like 100*cpu_operator_cost, and not think about how many rows
>> woul
On Thu, Aug 12, 2010 at 10:44 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Aug 11, 2010 at 5:12 PM, Tom Lane wrote:
>>> Yeah, possibly. It would probably be difficult for the planner to
>>> figure out where the cutover point is to make that worthwhile, though;
>>> the point where you'd
Robert Haas writes:
> On Wed, Aug 11, 2010 at 5:12 PM, Tom Lane wrote:
>> Yeah, possibly. It would probably be difficult for the planner to
>> figure out where the cutover point is to make that worthwhile, though;
>> the point where you'd need to make the transformation is long before we
>> have
On Wed, Aug 11, 2010 at 5:12 PM, Tom Lane wrote:
> Robert Haas writes:
>> In theory, the optimization Brian wants is possible here, right? I
>> mean, you could replace the functional call with a Param, and pull the
>> Param out and make it an InitPlan. Seems like that would generally be
>> a wi
On Wed, Aug 11, 2010 at 4:47 PM, Brian Ceccarelli wrote:
> Please show me an example where an inline query gets a performance boost.
Sure.
rhaas=# create table example as select a from
generate_series(1,10) a; SELECT 10
rhaas=# alter table example add primary key (a);
NOTICE: ALTER
Excerpts from Brian Ceccarelli's message of mié ago 11 16:47:50 -0400 2010:
> Please show me an example where an inline query gets a performance boost.
The reason it's a performance boost is that the query gets to be planned
as a single query, instead of there being a black-box that needs to be
p
Robert Haas writes:
> In theory, the optimization Brian wants is possible here, right? I
> mean, you could replace the functional call with a Param, and pull the
> Param out and make it an InitPlan. Seems like that would generally be
> a win, if you figure to loop more than once and the executio
Re: [BUGS] BUG #5611: SQL Function STABLE promoting to VOLATILE
Brian Ceccarelli writes:
> OK. The documentation says "allows the optimizer to optimize . . . ."
> But then the example guarantees the one-time-only for a index scan condition.
>
No, the documentation
Brian Ceccarelli writes:
> OK. The documentation says "allows the optimizer to optimize . . . ."
> But then the example guarantees the one-time-only for a index scan condition.
>
No, the documentation states that *if* an index scan is used, functions
involved in the indexscan's qual con
On Wed, Aug 11, 2010 at 11:50 AM, Brian Ceccarelli
wrote:
> OK. The documentation says "allows the optimizer to optimize . . . ."
> But then the example guarantees the one-time-only for a index scan condition.
>
> From the documentation: 8.4.4 Chapter 32 and 8.2.17 Chapter 33.
>
> .A ST
mailto:robertmh...@gmail.com]
Sent: Wednesday, August 11, 2010 11:33 AM
To: Brian Ceccarelli
Cc: Tom Lane; pgsql-bugs@postgresql.org
Subject: Re: [BUGS] BUG #5611: SQL Function STABLE promoting to VOLATILE
On Wed, Aug 11, 2010 at 11:01 AM, Brian Ceccarelli
wrote:
> My complaint
On Wed, Aug 11, 2010 at 11:01 AM, Brian Ceccarelli
wrote:
> My complaint remains. That inlined function f_return_ver_id_4() is a
> STABLE function, inlined or not. Postgres now calls it multiple times during
> the transaction, even though the arguments to f_return_ver_id_4() have not
> ch
Brian Ceccarelli writes:
> STABLE no longer means STABLE. This behavior is killing my performance.
> I am getting 500% to 3% increase in latency.
You seem to be under the illusion that "stable" is a control knob for a
function result cache. It is not, and never has been. Postgres do
ns out that in a SQL
function, now() also gets called multiple times.
The function f_return_ver_id_4() is a STABLE function. Even when
inlined, the behavior should still be that the function gets called only once
during a transaction
-Original Message-
From: Tom Lane [mailto:t...@ss
"Brian Ceccarelli" writes:
> --1. It seems that STABLE functions called within a SQL language
> get promoted to VOLATILE.
That has got nothing to do with it. The change in behavior from 8.2
is due to the fact that set-returning SQL functions can now be inlined.
The statement in f_pass_
The following bug has been logged online:
Bug reference: 5611
Logged by: Brian Ceccarelli
Email address: bceccare...@net32.com
PostgreSQL version: 8.4.4
Operating system: Windows XP 32 bit and Red Hat 5.4 64 bit
Description:SQL Function STABLE promoting to VOLATILE
De
17 matches
Mail list logo
