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.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers