Re: LargeObject API and OIDs

From: Christian Niles <christian(at)unit12(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: LargeObject API and OIDs
Date: 2004-10-25 14:03:09
Message-ID: 9A32C02E-268E-11D9-89C4-000A9590B78E@unit12.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Tom Lane 2004-10-25 14:28:00 Re: LargeObject API and OIDs
Previous Message Oliver Jowett 2004-10-25 10:35:31 Re: Problems with protocol V3 after migration to latest driver