From: | strk <strk(at)keybit(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | David Blasby <dblasby(at)refractions(dot)net>, postgis-users(at)postgis(dot)refractions(dot)net, pgsql-general(at)postgresql(dot)org |
Subject: | Re: [postgis-users] Union as an aggregate |
Date: | 2003-09-30 15:08:55 |
Message-ID: | 20030930170855.A5507@freek.keybit.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
tgl wrote:
> strk <strk(at)keybit(dot)net> writes:
> > If I run that again, *exactly the same query*:
> > PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
> > 566 pgsql 14 0 126M 126M 3396 S 0.0 16.8 7:13 postmaster
>
> > It looks like someone is leaking memory, either postgres, postgis or geos.
>
> On some platforms top's report of memory used can be misleading, because
> it begins to count each page of shared memory against a process when the
> process first touches that page. So if you have a big scan that touches
> more and more of the shared buffers, the reported process size goes up
> --- but there's really no memory leak. Try a plain "select count(*)"
> against your table and see if you see the same change in reported size.
No changes in size with count(*).
Testing platform is FreeBSD.
> Alternatively, if the reported size continues to increase well beyond
> your shared memory allocation, then I'd believe that as evidence of a
> leak.
>
> regards, tom lane
thanks for you answer.
--strk;
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-09-30 15:15:58 | Re: ADD FOREIGN KEY (was Re: [GENERAL] 7.4Beta) |
Previous Message | Stephan Szabo | 2003-09-30 14:53:28 | Re: ADD FOREIGN KEY (was Re: [GENERAL] 7.4Beta) |