Re: Large index operation crashes postgres

From: Frans Hals <fhals7(at)googlemail(dot)com>
To: Paul Ramsey <pramsey(at)cleverelephant(dot)ca>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Large index operation crashes postgres
Date: 2010-03-27 20:16:19
Message-ID: 39af1ed21003271316l6558d7g83d57ca9f1db411b@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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 | 5 | 1696900
ST_LineString | 6 | 1362231
ST_LineString | 7 | 1107733
ST_LineString | 8 | 915616
ST_LineString | 9 | 766904
ST_LineString | 10 | 646150
ST_LineString | 11 | 550356
ST_LineString | 12 | 473357
ST_LineString | 13 | 410038
ST_LineString | 14 | 358185
ST_LineString | 15 | 313985
ST_LineString | 16 | 278846
ST_LineString | 17 | 248253
ST_LineString | 18 | 220736
ST_LineString | 19 | 198809
ST_LineString | 20 | 179552
ST_LineString | 21 | 162140
ST_LineString | 22 | 147957
ST_LineString | 23 | 134321
ST_LineString | 24 | 123805
ST_LineString | 25 | 113805
ST_LineString | 26 | 105329
ST_LineString | 27 | 96809
ST_LineString | 28 | 90105
ST_LineString | 29 | 83137
ST_LineString | 30 | 77846
ST_LineString | 31 | 72963
ST_LineString | 32 | 67830
ST_LineString | 33 | 63849
ST_LineString | 34 | 60241
ST_LineString | 35 | 56312
ST_LineString | 36 | 52805
ST_LineString | 37 | 49919
ST_LineString | 38 | 47402
ST_LineString | 39 | 44860
ST_LineString | 40 | 41987
ST_LineString | 41 | 40055
ST_LineString | 42 | 38173
ST_LineString | 43 | 36649
ST_LineString | 44 | 34464
ST_LineString | 45 | 32637
ST_LineString | 46 | 31695
ST_LineString | 47 | 29851
ST_LineString | 48 | 28546
ST_LineString | 49 | 27419
ST_LineString | 50 | 26784
....
ST_LineString | 1993 | 2
ST_LineString | 1995 | 1
ST_LineString | 1997 | 6
ST_LineString | 1998 | 5
ST_LineString | 1999 | 3
ST_LineString | 2000 | 9
ST_Point | | 20648939
ST_MultiPolygon | | 6188
ST_Polygon | | 8054680

>One thing you could try is indexing each geometry type in turn and
>watch the memory usage.

If indexing starts sequentially from the beginning to the end, we
reach ST_Point around row 22.000.000. This is from the count of
geometry operations exactly where the slowdown begins.
Does this track us to the leak?

Thanks & regards
Frans

2010/3/26 Paul Ramsey <pramsey(at)cleverelephant(dot)ca>:

>
> Could you
> - put in your version information
> - tell me what kind of spatial objects you have? polygons of > 100
> vertices? lines of two vertices? etc. That will help me pick similar
> data for the memory testing.
>

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Frans Hals 2010-03-27 20:27:32 Re: Large index operation crashes postgres
Previous Message hubert depesz lubaczewski 2010-03-27 14:00:16 Re: How can I import a perl module into a plperl function ?