これら関数は、サーバーサイドとクライアントサイドの2種類が存在します。サーバーサイド関数は、データベースが動作しているサーバー内のファイルシステムを操作します。ドキュメントにある通り、様々なリスクがあるため、デフォルトではスーパーユーザー以外は操作できません。Aurora管理ユーザーは、サーバーサイド操作を行なえません。許可されていても、使いみちがありません。呼び出すと、権限不足エラーが発生します。接頭するクライアントサイド関数は呼び出せます。ラージオブジェクトは2Kbのページに分割されて保存されます。ラージオブジェクトのシステムカタログ(pg_largeobject)に問い合わせて確認します。インポートすると、7ページに渡って保存されました。オブジェクトIDを指定して、クライアント環境にエクスポートします。'/tmp/foo.json';lo_exportファイルのハッシュ値が同じことを確認します。いったサーバーサイド関数は、利用可能です。|このテーブルに、レコードを追加します。テーブルからレコードを削除しても、削除レコードが参照しているラージオブジェクトは残ったままです。rows)パージ処理を別途行わないと、ストレージが膨らみ続けてしまいます。呼び出すトリガーを設定します。lo_manage(raster);トリガー設定後に削除してみます。rows)今度は、レコードが参照しているラージオブジェクトも削除されました。同じラージオブジェクトを複数のレコードが参照している場合には、このようなシンプルなロジックは使えません。すると、トリガーは走りません。文や後述のパージ処理をご利用ください。該当するオブジェクトが存在するか、チェックします。テーブルに削除候補のオブジェクトが存在していますね。ドライランオプションを外して再実行します。削除されたことを確認できます。インストールできます。S3など)で管理する方法があります。S3の一番高いティアです。単純にGBあたりのコストを比較すると、ラージオブジェクト方式はデータベースストレージのコストが嵩み、S3方式の約5.7倍のストレージコストがかかります。PostgreSQLがラージオブジェクトに対応し、ラージオブジェクトを利用している既存PostgreSQLをAuroraへ移行しやすくなりました。ラージオブジェクトを利用すると、巨大なオブジェクトの管理をデータベースに任せられる一方で、実データを外部ストレージで管理する場合に比べてストレージコストが嵩み、不要オブジェクトのパージ運用も伴います。新規システムにラージオブジェクトを導入する際は、十分に事前評価してください。