But if I read the OP correctly the sigma are in fact used additively in
each row in blah. "sigma_* = sigma_* +"
matthias schoeneich wrote:
Hi,
as you don't seem to need the sigma_*'s, you could calc the whole
result with one query using:
CREATE OR REPLACE FUNCTION poly_example2() RETURNS S
Hi,
as you don't seem to need the sigma_*'s, you could calc the whole result
with one query using:
CREATE OR REPLACE FUNCTION poly_example2() RETURNS SETOF FLOAT8 AS
$poly_example$
DECLARE
f_result FLOAT8 := 0.0;
i_rowcount INT:= 0 ;
BEGIN
SELECT sum((RANDOM() * 100 ) * (term
Dear All
I need to simplify this query, It takes a lot of time to execute
Since "skala_rental" table has 2.3million rows(Table Size:387 MB, Indexes
Size: 132MB) and scanned 6 times in the execution. cf_application_id has
+10rows, Table Size: 21 MB, Indexes Size: 18MB
I guest the problem is on t
2009/10/10 Thom Brown
> I've had a look at examples of lag and lead window functions with order by
> inside the OVER clause, and I'm confused as to why it influences the overall
> order in the output.
> For example (for a table called category with incrementing id numbers up to
> 26):
>
> SELECT
On 2009-10-14, Shruthi A wrote:
> --0016e64698e4af821f0475e1f43d
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi,
>
> I'm using Enterprise DB PostgresPlus version 8.3.
> Is there is a simple function or command like previous_date(mydate) which
> when passed a particular date, simply returns
