From: | "Vadim B(dot) Mikheev" <vadim(at)sable(dot)krasnoyarsk(dot)su> |
---|---|
To: | Chris Albertson <chris(at)topdog(dot)pas1(dot)logicon(dot)com> |
Cc: | pgsql-questions(at)hub(dot)org, hackers(at)postgresql(dot)org |
Subject: | Re: [QUESTIONS] Postgresql dies with "FATAL 1: palloc failure: memory exhausted" |
Date: | 1998-04-02 01:37:27 |
Message-ID: | 3522EBD7.B5371AB8@sable.krasnoyarsk.su |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Chris Albertson wrote:
>
> This is just one example. ++Every time++ I do a SELECT where
> the expected result is a large number of rows I get a
> failure of some type.
>
> testdb=> select count(*) from tassm16
> testdb-> where 15.5 < b_mag::float4 - (0.375 * (b_mag -
> r_mag)::float4);
> FATAL 1: palloc failure: memory exhausted
> testdb=>
>
> I can make Postgresql 6.3 fail every time. Just do a SELECT
> where the number of rows returned is > a few million. The
0.375 above is float8 and so server uses two float8 funcs to
calculate right op of '<' ==> 2 * palloc(8) for each row.
palloc(8) eats more than 8 bytes of memmory (~ 24): 2 * 24 = 48,
48 * 1_million_of_rows = 48 Mb.
This is problem of all data types passed by ref !!!
And this is old problem.
Vadim
From | Date | Subject | |
---|---|---|---|
Next Message | Cristian Gafton | 1998-04-02 02:08:49 | 6.3.1 RH Linux 5.0 packages |
Previous Message | Vadim B. Mikheev | 1998-04-02 01:16:58 | Re: [HACKERS] Re: Let's talk up 6.3 |