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.
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 |