#author("2025-04-30T05:52:21+00:00","default:yoya","yoya")
#author("2025-04-30T05:52:42+00:00","default:yoya","yoya")
- データベース上の位置情報を効率的に検索する方法(PostgreSQL編)
-- http://neta.ywcafe.net/000597.html
- PostgreSQL Internals (1)
-- http://h50146.www5.hp.com/services/ci/opensource/pdfs/PostgreSQL_Internals.pdf
- [[ToroDB]] (JSON)
* 性能 [#perform]
-
-- http://d.hatena.ne.jp/yohei-a/20141122/1416638146
--- http://www.slideshare.net/hayamiz/ss-27192585
* ツール [#e35acec1]
* GUIツール [#gui]
- [[pgAdmin]]
- [[DBeaver]]
- [[TablePlus]]
* GPGPU [#gpgpu]
- (JP) GPGPUがPostgreSQLを加速する
-- http://www.slideshare.net/kaigai/jp-gpgpupostgresql
- PostgreSQLとMySQLで、僕がよく使うシステムコマンドのメモ
-- http://qiita.com/tamano/items/be43de7bb733ad38362c
* その他 [#k9d0c837]
- PostgreSQLは20年間どのようにfsyncを間違って使っていたか - 聴講メモ -
-- https://masahikosawada.github.io//2019/02/17/PostgreSQL-fsync-issue/
>
fsyncへの2つの間違った期待
>
1: fsyncが失敗した場合、次のfsyncのタイミングで失敗したdirty pageは再度書き込まれる
>
実際には・・・最初のfsyncに失敗したらデータはpage cacheから削除される。なので、次のfsyncはリトライしない。 さらに、これは、ファイルシステムによって挙動は変わる。ext4は、dirty dataをpage cacheにcleanとして残すし、xfsは捨てる。
>
2: 複数のファイルディスクリプタがある場合（例えばマルチプロセスの時）、一つのプロセスでfsyncが失敗したら、他のプロセスでも同じようにエラーとなる
>
実際には・・最初のプロセスだけがエラーとなる。その際、ファイルはcloseされopenされる。さらに、これはkernel versionによって挙動は異なる。
BSDでも同じように発生するけど、FreeBSD、illumosでは起きない。
* 関連 [#rel]
- [[Database]]
