PostGISの新しい関数のリストは増え続けており、その一部にはGEOS（たとえばST_ClusterKMeans）が含まれています。一部の関数（などpgrouting）は他のライブラリ（例BGL）に依存しています。
私の印象では、これらの基礎となるライブラリの多く（多くの場合C / C ++）は、メモリとセカンダリメモリ/ストレージ/ディスク間のバッファ管理を処理しません。
では、それらの上にあるPostGIS関数は、物理（または仮想）メモリに保存できない大きなデータセットで動作しますか？
もしそうなら、これらのバッファ管理機能はどこから来ますか（実装の観点から）？
回答:
いいえ、これらの「高次分析」機能のほとんどは、メモリに収まるよりも大きいデータセットに対する特別な処理を行いません。そのようなデータセットでそれらを実行する場合、バックエンドをOOMするだけです。
しばらくの間、そのような関数を作成することは避けましたが、デフォルトでRAMが大きくなり、より多くの分析が必要になり、メモリー制限に達することは比較的少ないため、利点/欠点の方程式は「やるだけ」に移行しました。
これらの関数の中で最も古いものであるST_Union（）は、もともとメモリバウンドにならないように構築され、パフォーマンスが（非常に高い）犠牲になりました。「mem」は「メモリセーフ」を意味するため、元の関数ST_MemUnion（）を引き続き使用できます。この関数は（紛らわしいことに）実際に使用するメモリが少なくなります。
十分なデータを提供すると、さまざまなクラスターであるST_Buffer（）などの他の関数がOOMになります。