Re: Memory deallocation after calling cast function

Hi

I have problem with memory deallocation. look at the following queries

1- create table test01(a) as select generate_series(1,100000000)::int8 ;

2- create table test02(a) as select generate_series(1,100000000) ;

In execution of first query, memory usage increase rapidly until the
transaction comes to end and deallocate all the memory which allocated with
palloc.
I have wondered why all the memory deallocated at the end, so the cast is
removed and query executed again. memory usage was not the same. It was
grow very slow.

I need help to find the right point to deallocate the memory,
Any idea will be appreciated.

Soroosh Sardari

Soroosh Sardari <soroosh(dot)sardari(at)gmail(dot)com> writes:
> I have problem with memory deallocation. look at the following queries

> 1- create table test01(a) as select generate_series(1,100000000)::int8 ;

Do it as, eg,

create table test01(a) as select g::int8 from generate_series(1,100000000) g;

SRFs in the SELECT targetlist tend to leak memory; this is not easily
fixable, and nobody is likely to try hard considering the feature's on
the edge of deprecation anyhow.

regards, tom lane

On Tue, Jun 3, 2014 at 03:59:45PM -0400, Tom Lane wrote:
> Soroosh Sardari <soroosh(dot)sardari(at)gmail(dot)com> writes:
> > I have problem with memory deallocation. look at the following queries
>
> > 1- create table test01(a) as select generate_series(1,100000000)::int8 ;
>
> Do it as, eg,
>
> create table test01(a) as select g::int8 from generate_series(1,100000000) g;
>
> SRFs in the SELECT targetlist tend to leak memory; this is not easily
> fixable, and nobody is likely to try hard considering the feature's on
> the edge of deprecation anyhow.

Uh, what is replacing SRFs? CTEs?

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

At 2014-06-17 11:32:37 -0400, bruce(at)momjian(dot)us wrote:
>
> > SRFs in the SELECT targetlist tend to leak memory; this is not easily
> > fixable, and nobody is likely to try hard considering the feature's on
> > the edge of deprecation anyhow.
>
> Uh, what is replacing SRFs? CTEs?

I don't think Tom was referring to SRFs in general, only putting them
directly into the targetlist of a SELECT.

-- Abhijit

On 2014-06-17 21:09:25 +0530, Abhijit Menon-Sen wrote:
> At 2014-06-17 11:32:37 -0400, bruce(at)momjian(dot)us wrote:
> >
> > > SRFs in the SELECT targetlist tend to leak memory; this is not easily
> > > fixable, and nobody is likely to try hard considering the feature's on
> > > the edge of deprecation anyhow.
> >
> > Uh, what is replacing SRFs? CTEs?
>
> I don't think Tom was referring to SRFs in general, only putting them
> directly into the targetlist of a SELECT.

And the primary reason for using SRFs in the targetlist has gone away
due to LATERAL. It's now possible to pass data from tables to a SRF,
that previously wasn't possibly unless you'd used a SRF in the targetlist.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> On 2014-06-17 21:09:25 +0530, Abhijit Menon-Sen wrote:
>> At 2014-06-17 11:32:37 -0400, bruce(at)momjian(dot)us wrote:
>>> Uh, what is replacing SRFs? CTEs?

>> I don't think Tom was referring to SRFs in general, only putting them
>> directly into the targetlist of a SELECT.

> And the primary reason for using SRFs in the targetlist has gone away
> due to LATERAL.

Exactly. LATERAL does what you usually want from a SRF in the
targetlist, and it doesn't have bizarre semantics when you use more than
one.

regards, tom lane