GiST memory usage
Hi all.
I've been reported memory limit hits
during a postgis index construction
(GiST index).
The indexed tuples are about 425 millions.
The index key is a box2d object (4*sizeof(float)).
The machine has 4 Gb of RAM, and operations are
peaked at ~2.4 Gb of usage.
Is there a way to detect where is memory hold ?
Is there an index-specific memory context for use
to early release memory blocks allocated during
operations (didn't see any use of memory contexts
in the contrib/rtree_gist) ?
TIA
--strk;
Missing info for the report:
win32
postgresql 8.0.3
maintenance_work_mem 512
btree index on oid works fine
--strk;
Show quoted text
On Sat, Aug 13, 2005 at 01:12:30PM +0200, strk@refractions.net wrote:
Hi all.
I've been reported memory limit hits
during a postgis index construction
(GiST index).The indexed tuples are about 425 millions.
The index key is a box2d object (4*sizeof(float)).The machine has 4 Gb of RAM, and operations are
peaked at ~2.4 Gb of usage.Is there a way to detect where is memory hold ?
Is there an index-specific memory context for use
to early release memory blocks allocated during
operations (didn't see any use of memory contexts
in the contrib/rtree_gist) ?TIA
--strk;
Is there a way to detect where is memory hold ?
Look at postgis code. We constructed rtree_gist index over 1e9 rows (on 8.0 pgsql).
Is there an index-specific memory context for use
to early release memory blocks allocated during
operations (didn't see any use of memory contexts
in the contrib/rtree_gist) ?
8.1 pgsql has short lived memory context during index creation which resets
after every insert. 8.0 hasn't this feature, so user-defined function (GiST
interfface) should carefully clean memory.
--
Teodor Sigaev E-mail: teodor@sigaev.ru
WWW: http://www.sigaev.ru/