Re: Large index operation crashes postgres - Mailing list 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@cleverelephant.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.
>