On 11/01/2011 10:01 PM, Sabin Coanda wrote:
Hi there,
I have the function:
CREATE OR REPLACE FUNCTION "Test"( ... )
RETURNS SETOF record AS
$BODY$
BEGIN
RETURN QUERY
SELECT ...;
END;
$BODY$
LANGUAGE 'plpgsql' STABLE
The function call takes about 5 minute to proceed, but using directly its
The most common reason for this (not specific to PG) is that the function
is getting compiled without the substituted constants, and the query plan
is generic, whereas with specific values it is able to use column
statistics to pick a more efficient one.
On Nov 1, 2011 8:16 PM, "Sabin Coanda" wrot
Hi there,
I have the function:
CREATE OR REPLACE FUNCTION "Test"( ... )
RETURNS SETOF record AS
$BODY$
BEGIN
RETURN QUERY
SELECT ...;
END;
$BODY$
LANGUAGE 'plpgsql' STABLE
The function call takes about 5 minute to proceed, but using directly its
query statement, after replacing the arguments w
Marcus Engene writes:
> After I upgraded from Postgres 8.3/8.4 to 9.0 I had all sorts of
> problems with queries with many joins. Queries that used to take 1ms
> suddenly take half a minute for no apparent reason.
Could we see a concrete test case, rather than hand waving? If there's
really a
On 1 Listopad 2011, 10:57, Marcus Engene wrote:
> Hi Hashim,
>
> One workaround I've done is if something looking like this
>
> select
> ...
> from
> table_linking_massive_table tlmt
> ,massive_table mt
> ,some_table1 st1
> ,some_table2 st2
> ,some_table3 st3
> ,so
On Tue, Nov 01, 2011 at 08:33:51AM +0530, Mohamed Hashim wrote:
> Any idea or suggestions how to improve my database best
> performance.???
>
> Regards
> Hashim
>
Hi Hashim,
Ignoring the description of your tables, you should probably try
updating to the latest release 9.0.5. You
Hi Hashim,
After I upgraded from Postgres 8.3/8.4 to 9.0 I had all sorts of
problems with queries with many joins. Queries that used to take 1ms
suddenly take half a minute for no apparent reason.
I have 72GB which I think makes the planner go bonkers and be too eager
doing a seq scan. I tri
