On Wed, Oct 21, 2009 at 12:37 AM, Pavel Stehule wrote:
> 2009/10/21 Merlin Moncure :
>> On Tue, Oct 20, 2009 at 5:12 PM, Pavel Stehule
>> wrote:
[ shrug... ] There are other possible reasons why the planner would
fail to flatten a subquery, but none of them apply to the example you
>>
2009/10/21 Merlin Moncure :
> On Tue, Oct 20, 2009 at 5:12 PM, Pavel Stehule
> wrote:
>>> [ shrug... ] There are other possible reasons why the planner would
>>> fail to flatten a subquery, but none of them apply to the example you
>>> showed. And your example function *was* VOLATILE, by defaul
On Tue, Oct 20, 2009 at 5:12 PM, Pavel Stehule wrote:
>> [ shrug... ] There are other possible reasons why the planner would
>> fail to flatten a subquery, but none of them apply to the example you
>> showed. And your example function *was* VOLATILE, by default.
>
> I checked this on 8.5 and fun
Hello
2009/10/19 Tom Lane :
> Gerhard Wiesinger writes:
>> On Mon, 19 Oct 2009, Tom Lane wrote:
>>> Probably because you have the function declared VOLATILE.
>
>> None of the function is declared VOLATILE. Any other idea?
>
> [ shrug... ] There are other possible reasons why the planner would
>
Gerhard Wiesinger writes:
> On Mon, 19 Oct 2009, Tom Lane wrote:
>> Probably because you have the function declared VOLATILE.
> None of the function is declared VOLATILE. Any other idea?
[ shrug... ] There are other possible reasons why the planner would
fail to flatten a subquery, but none of
On Oct 19, 2009, at 10:49 AM, Gerhard Wiesinger wrote:
None of the function is declared VOLATILE. Any other idea?
If they are not declared with a volatility category at all, the
default is VOLATILE. Is that a possibility?
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-g
On Mon, 19 Oct 2009, Tom Lane wrote:
Gerhard Wiesinger writes:
On Sun, 18 Oct 2009, Tom Lane wrote:
The OFFSET bit is a kluge, but is needed to keep the planner from
flattening the subquery and undoing your work.
Thnx Tom. It also works without the OFFSET kludge. Any ideas why?
Probably
Gerhard Wiesinger writes:
> On Sun, 18 Oct 2009, Tom Lane wrote:
>> The OFFSET bit is a kluge, but is needed to keep the planner from
>> flattening the subquery and undoing your work.
> Thnx Tom. It also works without the OFFSET kludge. Any ideas why?
Probably because you have the function decla
On Sun, 18 Oct 2009, Tom Lane wrote:
Gerhard Wiesinger writes:
Since getSums() is a cursor and is complex and takes long time getSums
should only be evaluated once. Is there a better solution available to
get both columns from the function in the select?
You need a sub-select, along the line
Gerhard Wiesinger writes:
> Since getSums() is a cursor and is complex and takes long time getSums
> should only be evaluated once. Is there a better solution available to
> get both columns from the function in the select?
You need a sub-select, along the lines of
SELECT
cur_date,
(gs).su
Hello,
I'm having a problem with the following:
CREATE TYPE Sums AS (sum_m1 double precision, sum_m2 double precision);
CREATE TYPE date_m1_m2 AS (cur_date date, sum_m1 double precision, sum_m2
double precision);
CREATE OR REPLACE FUNCTION getSums(IN start_ts timestamp with time
zone, IN stop
11 matches
Mail list logo
