PostGIS의 새로운 기능 목록이 점점 늘어나고 있으며 그 중 일부에는 GEOS(예 :)가 포함되어 있습니다 ST_ClusterKMeans. 일부 기능 (예 :의 기능 pgrouting)은 다른 라이브러리 (예 :)를 사용 BGL합니다.
필자는 이러한 기본 라이브러리 (주로 C / C ++에서)의 많은 부분이 메모리와 보조 메모리 / 스토리지 / 디스크 사이의 버퍼 관리를 처리 하지 않는다고 생각 합니다.
그렇다면 PostGIS 기능은 물리적 (또는 가상) 메모리에 저장할 수없는 대용량 데이터 세트에서 작동합니까?
그렇다면 이러한 버퍼 관리 기능은 어디에서 시작합니까 (구현 관점에서)?
답변:
아니요, 이러한 "고차 분석"기능의 대부분은 메모리에 들어갈 수있는 것보다 큰 데이터 세트에 대한 특별한 처리가 없습니다. 그러한 데이터 세트에서 실행하면 백엔드를 OOM합니다.
한동안 우리는 그러한 기능을 만들지 않았지만 기본적으로 RAM이 커지고 사람들이 더 많은 분석을 원했고 상대적으로 적은 수의 메모리 한계에 도달했을 때 이점 / 단점 방정식은 "그냥해라"라는 호의로 바뀌 었습니다.
이 함수 중 가장 오래된 ST_Union ()은 원래 성능이 매우 높은 비용으로 메모리에 바인딩 되지 않도록 작성되었습니다 . 당신은 여전히 원래의 기능, ST_MemUnion (), (혼동) 실제로 사용하는 사용할 수 있습니다 덜 은 "MEM은"수단 "메모리 안전"이후, 메모리를.
다양한 클러스터 인 ST_Buffer ()와 같은 다른 함수는 충분한 데이터를 제공하면 OOM이됩니다.