e on that operator being deprecated?
regards, matt bannert
From: Tom Lane [t...@sss.pgh.pa.us]
Sent: Saturday, April 09, 2016 5:25 PM
To: Bannert Matthias
Cc: Charles Clavadetscher; pgsql-general@postgresql.org
Subject: Re: [GENERAL] max_stack_depth pr
y?
regards, matt bannert
________________
From: Tom Lane [t...@sss.pgh.pa.us]
Sent: Friday, April 08, 2016 9:39 PM
To: Bannert Matthias
Cc: Charles Clavadetscher; pgsql-general@postgresql.org
Subject: Re: [GENERAL] max_stack_depth problem though query is substantially
sm
bject: Re: [GENERAL] max_stack_depth problem though query is substantially
smaller
"Bannert Matthias" writes:
> Thanks for your reply. I do think it is rather a postgres than an R issue,
> here's why:
> a) R simply puts an SQL string together. What Charles had posted was
"Bannert Matthias" writes:
> Fwiw, I was not stubbornly insisting on nesting operators. Actually I
> switched from "=>" to the hstore function cause
> a note in the manual said it was deprecated
> (http://www.postgresql.org/docs/9.0/static/hstore.html). Somehow I must have
> understand that no
"Bannert Matthias" writes:
> [ very deep stack of parser transformExprRecurse calls ]
> #20137 0x7fe7fb80ab8c in pg_analyze_and_rewrite
> (parsetree=parsetree@entry=0x7fe7fffdb2a0,
> query_string=query_string@entry=0x7fe7fdf606b0 "INSERT INTO
> ts_updates(ts_key, ts_data, ts_frequency) VA
"Bannert Matthias" writes:
> Thanks for your reply. I do think it is rather a postgres than an R issue,
> here's why:
> a) R simply puts an SQL string together. What Charles had posted was an
> excerpt of that string.
> Basically we have 1.7 MB of that string. Everything else is equal just the
ge
and thus a query string that only has 1.7 MB exceeds the stack ?
From: Tom Lane [t...@sss.pgh.pa.us]
Sent: Friday, April 08, 2016 4:20 PM
To: Charles Clavadetscher
Cc: pgsql-general@postgresql.org; Bannert Matthias
Subject: Re: [GENERAL] max_stack_
"Charles Clavadetscher" writes:
> When R processes the daily time serie we get a stack size exceeded
error, followed by the hint to increase the max_stack_depth.
Postgres doesn't generally allocate large values on the stack, and I doubt
that R does either. Almost certainly, what is causing this
Charles Clavadetscher wrote:
> We have a process in R which reads statistical raw data from a table and
> computes time series values
> from them.
> The time series values are in a hstore field with the date as the key and the
> value as the value.
> The process writes the computed value into a t
Hello
We have a process in R which reads statistical raw data from a table and
computes time series values from them.
The time series values are in a hstore field with the date as the key and the
value as the value.
The process writes the computed value into a temporary table and locks the
corr
10 matches
Mail list logo
