Re: LargeObject API and OIDs
От | Christian Niles |
---|---|
Тема | Re: LargeObject API and OIDs |
Дата | |
Msg-id | 9A32C02E-268E-11D9-89C4-000A9590B78E@unit12.net обсуждение исходный текст |
Ответ на | Re: LargeObject API and OIDs (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: LargeObject API and OIDs
|
Список | pgsql-jdbc |
On Oct 24, 2004, at 4:26 PM, Tom Lane wrote: > > No; instead you'd get a failure during lo_create: > > /* Check for duplicate (shouldn't happen) */ > if (LargeObjectExists(file_oid)) > elog(ERROR, "large object %u already exists", file_oid); > > You could deal with this by retrying lo_create until it succeeds. > However, if you are expecting more than a few tens of millions of > objects, you probably don't want to go this route because the > probability of collision will be too high; you could spend a long time > iterating to find a free OID. Something involving a bigint identifier > would work better. If i understand correctly, you're implying here using a table that mimics the pg_largeobject table, but uses int/bigint identifiers instead of OID. Are there any optimizations that make the LargeObject API significantly faster? From the documentation, it seems that as long as I use prepared/callable statements, this shouldn't incur much additional overhead. thanks again, christian.
В списке pgsql-jdbc по дате отправления: