postgresqlのlarge object
1857 ワード
// ,pg_largeobject_metadata , pg_largeobject
CATALOG(pg_largeobject_metadata,2995)
{
Oid lomowner; /* OID of the largeobject owner */
#ifdef CATALOG_VARLEN /* variable-length fields start here */
aclitem lomacl[1]; /* access permissions */
#endif
} FormData_pg_largeobject_metadata;
/*
* Each "page" (tuple) of a large object can hold this much data
*
* We could set this as high as BLCKSZ less some overhead, but it seems
* better to make it a smaller value, so that not as much space is used
* up when a page-tuple is updated. Note that the value is deliberately
* chosen large enough to trigger the tuple toaster, so that we will
* attempt to compress page tuples in-line. (But they won't be moved off
* unless the user creates a toast-table for pg_largeobject...)
*
* Also, it seems to be a smart move to make the page size be a power of 2,
* since clients will often be written to send data in power-of-2 blocks.
* This avoids unnecessary tuple updates caused by partial-page writes.
*/
#define LOBLKSIZE (BLCKSZ / 4)
CATALOG(pg_largeobject,2613) BKI_WITHOUT_OIDS
{
Oid loid; /* Identifier of large object */
int4 pageno; /* Page number (starting from 0) */
/* data has variable length, but we allow direct access; see inv_api.c */
bytea data; /* Data for page (may be zero-length) */
} FormData_pg_largeobject;
すべての大きいオブジェクトはすべてLOBLKSIZEの大きさに分解して、pg_を入れますLargeobjectではloidで区別し,各大オブジェクトが分割する各部分はpageno(メタグループ番号と呼ぶ方が合理的)で順序の関連付けを行い,
pagenoは、書き込むデータoffset/LOBLKSIZEで計算されます
pgの大きいオブジェクトの実現は比較的に簡単で、大きいデータ量の使用に適していない、システムのボトルネックになる.