=?ISO-8859-1?Q?Dennis_Bj=F6rklund?= <[EMAIL PROTECTED]> writes:
> On Sun, 3 Aug 2003, Tom Lane wrote:
>> I added code to inline_function to stop inlining if a parameter
>> expression to be substituted multiple times has cost greater than
>> 10*cpu_operator_cost (which roughly means that it contains
On Sun, 3 Aug 2003, Tom Lane wrote:
> I added code to inline_function to stop inlining if a parameter
> expression to be substituted multiple times has cost greater than
> 10*cpu_operator_cost (which roughly means that it contains more than
> 10 operators or functions).
When is this inlining taki
Tom Lane wrote:
I added code to inline_function to stop inlining if a parameter
expression to be substituted multiple times has cost greater than
10*cpu_operator_cost (which roughly means that it contains more than
10 operators or functions). This seems to cut off the problem nicely,
at least for
I said:
> There is some code in the function inliner to abandon inlining if an
> input expression is "too expensive", but its notion of "too expensive"
> is currently just "contains subselects". I'm going to see if it helps
> to reject inlining when the input grows "too large", for some value of
>
Joe Conway <[EMAIL PROTECTED]> writes:
> But I wonder why it isn't at all a problem when the function is also
> defined STRICT?
Because the inliner doesn't think it can safely inline in that case; the
substituted expression isn't strict and so inlining would potentially
change the semantics.
"Tom Lane" <[EMAIL PROTECTED]> wrote:
> Joe Conway <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> It seems to be running out of memory.
>
> > Also worth noting, without STRICT, even a plain EXPLAIN *without*
> > ANALYZE causes the problem to show itself.
>
> Yeah. The problem is that the
Tom Lane wrote:
Yeah. The problem is that the SQL function inliner generates an
enormous expression tree from this function definition. 7.3 had no
inliner so no problem.
But I wonder why it isn't at all a problem when the function is also
defined STRICT?
I also looked back at the greatest() exa
Joe Conway <[EMAIL PROTECTED]> writes:
> regression=# select
> concat_ws('~','01','02','03','04','05','06','07','08','09','10','11','12','13','14','15','16','17','18','19','20','21','22','23','24');
> ERROR: ERRORDATA_STACK_SIZE exceeded
With the removal of some overoptimistic code in elog.c, I
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> It seems to be running out of memory.
> Also worth noting, without STRICT, even a plain EXPLAIN *without*
> ANALYZE causes the problem to show itself.
Yeah. The problem is that the SQL function inliner generates an
enormous expression
Tom Lane wrote:
It seems to be running out of memory. I'm not sure what's eating so
much RAM --- the expression isn't that complex. Also it seems that
elog.c's ability to handle a shortage of memory has regressed ...
'ERROR: ERRORDATA_STACK_SIZE exceeded' is better than a core dump,
I suppose, b
Joe Conway <[EMAIL PROTECTED]> writes:
> I thought I'd whack out this example similar to the GREATEST/LEAST
> functions a month or so ago. It works fine in 7.3, but has a problem on
> 7.4devel. First the function:
It seems to be running out of memory. I'm not sure what's eating so
much RAM ---
Tom Lane wrote:
I think you'd need to generate a separate function definition for
each number of arguments you wanted to deal with, which is a bit
of a pain in the neck, but it still beats writing an extension
function in C ...
I thought I'd whack out this example similar to the GREATEST/LEAST
fun
Hans Spaans <[EMAIL PROTECTED]> writes:
> Currently I'm working on porting a mysql-app to postgresql and they're
> using concat_ws[1], but I'm currently can't find anything like it in
> postgresql. Or did I overlooked something in the documentation?
There's nothing like that built-in, but you coul
I think that you should write your own stored procedure.
Regards
Gaetano Mendola
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Hello all,
Currently I'm working on porting a mysql-app to postgresql and they're
using concat_ws[1], but I'm currently can't find anything like it in
postgresql. Or did I overlooked something in the documentation?
Kind regards,
Hans
[1] http://www.mysql.com/doc/en/String_functions.html
--
Han
15 matches
Mail list logo
