Postgres Pro
Downloads
Home   >   mailing lists

Thread: Memory deallocation after calling cast function

Memory deallocation after calling cast function

From
Soroosh Sardari
Date:
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

Re: Memory deallocation after calling cast function

From
Tom Lane
Date:
Soroosh Sardari <soroosh.sardari@gmail.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

Re: Memory deallocation after calling cast function

From
Bruce Momjian
Date:
On Tue, Jun  3, 2014 at 03:59:45PM -0400, Tom Lane wrote:
> Soroosh Sardari <soroosh.sardari@gmail.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@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +

Re: Memory deallocation after calling cast function

From
Abhijit Menon-Sen
Date:
At 2014-06-17 11:32:37 -0400, bruce@momjian.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

Re: Memory deallocation after calling cast function

From
Andres Freund
Date:
On 2014-06-17 21:09:25 +0530, Abhijit Menon-Sen wrote:
> At 2014-06-17 11:32:37 -0400, bruce@momjian.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

Re: Memory deallocation after calling cast function

From
Tom Lane
Date:
Andres Freund <andres@2ndquadrant.com> writes:
> On 2014-06-17 21:09:25 +0530, Abhijit Menon-Sen wrote:
>> At 2014-06-17 11:32:37 -0400, bruce@momjian.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