random, might be a clue, we'll see. So it looks like much of
> the table is two-point lines and points.
>
> P
>
> On Sat, Mar 27, 2010 at 1:16 PM, Frans Hals wrote:
>
>> ST_Point | | 20648939
>> ST_MultiPolygon | | 61
Paul,
took your advice and installed Geos 3.2.0.
Index is now running for 14 hrs, postmaster is taking all the RAM.
Sadly it looks like the Geos update didn't save me.
Regards
Frans
2010/3/28 Paul Ramsey :
> GEOS 3.2 is backwards compatible, so you can install it overtop of 3.1
> and things will
Paul,
do you know, if Postgis 1.3.6 will survive, if I install Geos 3.2 over
it? Currently, there's Geos 3.1.1 installed.
I remember, I had to downgrade Postgis/Geos to be compatible with
Postgres 8.3.9. As I "herited" the database from a 8.3.9 dump, I
needed to fit my installation before restori
Paul,
I kindly received the information about the table data (quoting here):
>It changes as it goes down the table, it's a right mixture.
ST_LineString |2 | 5398548
ST_LineString |3 | 2877681
ST_LineString |4 | 2160809
ST_LineString |
The index mentioned below has been created in some minutes without problems.
Dropped it and created it again. Uses around 36 % of memorywhile
creating, after completion postmaster stays at 26 %.
> I'm not sure, what you're thinking about generating a self-contained
> test that exhibits similar bl
Tom,
I'm pretty new to memory debugging, so please be patient if I'm not as
precise as you suppose me to be.
For the records I have run a valgrind postmaster session, starting my
initial indexing routine until it crashes postgres.
If you think this might be enlightning for you, I'll send you the
t
Operation is now running for around 13 hrs.
Two postmaster processes above 1% memory usage are running.
One of them uses constantly 26.5% of memory.
The other one is growing:
After 1 hr25%
After 9 hrs 59%
After 13 hrs64%
Thanks & regards
Frans
2010/3/25 Frans Hals :
&g
Paul,
I have started the operation right now after a fresh reboot of the machine.
Please give me some time to collect the results...
Thanks & regards
Frans
2010/3/25 Paul Ramsey :
> If you build an index, or try to update a column, using just the
>
> ST_X(ST_Centroid())
>
> without all the ext
Tom,
ran a CREATE INDEX to the gdb operated postmaster.
Nothing new due to missing debugging libraries, so this might not help:
Reading symbols from /usr/bin/postmaster...(no debugging symbols found)...done.
Missing separate debuginfos, use: debuginfo-install
postgresql-server-8.3.9-1PGDG.f12.x86
5 x postmaster taking memory:
93.3 %
18.7 %
0.3 %
0.2 %
0.0 %
112.5%
Looks like there is someone living beyond its means?
Frans
2010/3/24 Tom Lane :
> Hm. I wonder about a memory leak in there somewhere. Have you checked
> the process size while this is going on?
>
>
Hi,
running a geo-database from a dump restore where still one of the most
important indexes is missing and so the search is slow.
Whenever I try to add the follwing index to the table "placex", one of
the postmaster processes dies and the server restarts.
I try:
CREATE INDEX idx_placex_sector ON
11 matches
Mail list logo
