ogr2ogr command for each layer.
-Jukka Rahkonen-
*Lähettäjä:* gdal-dev *Puolesta
*Alexandre Gacon
*Lähetetty:* maanantai 23. toukokuuta 2022 17.39
*Vastaanottaja:* Jan Heckman
*Kopio:* gdal-dev
*Aihe:* Re: [gdal-dev] ogr2ogr Postgres upload performance
I will try this
er.
>
>
>
> -Jukka Rahkonen-
>
>
>
> *Lähettäjä:* gdal-dev *Puolesta *Alexandre
> Gacon
> *Lähetetty:* maanantai 23. toukokuuta 2022 17.39
> *Vastaanottaja:* Jan Heckman
> *Kopio:* gdal-dev
> *Aihe:* Re: [gdal-dev] ogr2ogr Postgres upload performance
>
>
>
> I w
Vastaanottaja: Jan Heckman
Kopio: gdal-dev
Aihe: Re: [gdal-dev] ogr2ogr Postgres upload performance
I will try this way. To turn of SI creation : SPATIAL_INDEX=NONE
Le lun. 23 mai 2022 à 15:15, Jan Heckman
mailto:jan.heck...@gmail.com>> a écrit :
Perhaps the spatial index update (in
I meant : "I used the "PG_USE_COPY *yes*" option without any other
refinements"
Med venlig hilsen / Kind regards
Bo Victor Thomsen
Den 24-05-2022 kl. 08:11 skrev Alexandre Gacon:
As far as I remember, I used the "PG_USE_COPY no" option without any
other refinements. But I didn't append
Hello,
The PG_USE_COPY parameter doesn't seem to work when appending several files
in the same table (replace the old data or something like that).
Postponing the creation of the spatial index does not seem to improve
things either.
I didn't try increasing the number of rows per transaction but
Hi,
Thank you for the input. I will give a try to different combination and
share my results.
Alexandre
Le lun. 23 mai 2022 à 19:43, Bo Victor Thomsen
a écrit :
> Hi Alexandre -
>
> I made a DOS script ages ago to try the different use cases. It's inserted
> as text below. It doesn't test ever
Hi Alexandre -
I made a DOS script ages ago to try the different use cases. It's
inserted as text below. It doesn't test every setup combination, only
the most pertinent.
The base gpkg layer is all the buildings i Denmark, ca. 5.8 million objects.
For my layer I had the following results:
1
I will try this way. To turn of SI creation : *SPATIAL_INDEX*=NONE
Le lun. 23 mai 2022 à 15:15, Jan Heckman a écrit :
> Perhaps the spatial index update (in de DB) slows the insertion.
> It might be more efficient to not create the SI in the first run,
> then insert more rows and create the SI a
Perhaps the spatial index update (in de DB) slows the insertion.
It might be more efficient to not create the SI in the first run,
then insert more rows and create the SI after all is done.
I don't know how to turn off SI creation in the command line.
On Mon, May 23, 2022 at 3:04 PM Alexandre Gaco
Hello,
I am using ogr2ogr to upload data from several geopackages to a postgis
database. Some tables contain thousands of rows (buildings for example).
The import of the first file is quite fast (tables are created for the
first file so PG_USE_COPY is used) but the following file is much slower
(
10 matches
Mail list logo
