Po sugestii user30184 , Paul Ramsey i moje własne eksperymenty. Postanowiłem odpowiedzieć na to pytanie.
W tym pytaniu nie wspomniałem, że importuję dane na zdalny serwer. (chociaż jest to opisane w poście na blogu, do którego się odnoszę). Operacje takie jak wstawianie przez Internet podlegają opóźnieniu sieci. Być może nie jest bez znaczenia wspomnienie, że ten serwer jest na Amazon RDS , co uniemożliwia mi ssh na maszynie i uruchamianie operacji lokalnie.
Mając to na uwadze, przeprojektowałem swoje podejście, wykorzystując dyrektywę „\ copy”, aby promować zrzut danych do nowej tabeli. Myślę, że ta strategia jest niezbędnym kluczem, do którego również odniesiono się w komentarzach / odpowiedziach na to pytanie.
psql database -U user -h host.eu-west-1.rds.amazonaws.com -c "\copy newt_table from 'data.csv' with DELIMITER ','"
Ta operacja była niesamowicie szybka. Ponieważ zaimportowałem plik csv, miałem całą pracę nad wypełnieniem geometrii, dodaniem indeksu przestrzennego itp. Było to nadal niezwykle szybkie, ponieważ wtedy uruchamiałem zapytania na serwerze .
Postanowiłem przeprowadzić analizę porównawczą również sugestii użytkownika 30184 , Paula Ramseya . Mój plik danych był punktowym plikiem kształtu z 3035369 rekordami i 82 MB.
Podejście ogr2ogr (przy użyciu dyrektywy PG_USE_COPY) zakończyło się w 1:03:00 m, co jest wciąż * znacznie lepsze niż wcześniej.
Metoda shp2pgsql (wykorzystująca dyrektywę -D) zakończyła się tylko 00:01:04 m.
Warto powiedzieć, że ogr2ogr stworzył indeks przestrzenny podczas operacji, a shp2pgsql nie. Przekonałem się, że tworzenie importu po dokonaniu importu jest znacznie bardziej wydajne , niż rozdęcie operacji importowania tego typu żądaniem.
Wniosek jest następujący: shp2pgsql, jeśli jest odpowiednio sparametryzowany, doskonale nadaje się do przeprowadzania dużych importów, a mianowicie tych, które są dostępne w ramach usług Amazon Web Services.
Możesz przeczytać bardziej szczegółowy opis tych wniosków, dotyczący aktualizacji tego postu.
