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  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Oliver Jowett
Дата:
Сообщение: Re: Problems with protocol V3 after migration to latest driver
Следующее
От: Tom Lane
Дата:
Сообщение: Re: LargeObject API and OIDs