Hi.
> <itagaki.takahiro@oss.ntt.co.jp> wrote:
> (It would be a rare case, but) A large object might be referenced
> by two or more rows because LO interface is split into two steps;
> allocating oid and storing data for it. The oid could be stored in
> two or more places and auto deletion would break such usecases.
Indeed. We have to check the references on garbage collecting.
For this reason, my plan B "Merge contrib/vacumelo to VACUUM" is
easier to implement.
> BTW, bytea and TOASTing would works perfectly as you expected.
> Why don't you use bytea instead of large objects? In other words,
> what you want actually is not LO improvement but efficient TOASTing, no?
First of all, what I want is to contribute to PostgreSQL community by
writing patches.
And picked this issue up from TODO list.
So if there's no need to do about this issue, I will pick up another one :-)
I've checked some articles about "Oid large objects vs bytea".
If I understand them correctly, I think
both large objects and bytea are useful for different situations.
Neither of them are obsolete.
Is there no need to do about this issue?
Cheers.
==========================================================
the negative points of bytea: memory hungry. slower than large objects. 1GB limitation.
the negative points of large objects: ghost problem (no auto-delete). unable to store number of objects greater than
2^32.
==========================================================
-----
Taro Minowa(Higepon)
Cybozu Labs, Inc.
http://www.monaos.org/
http://code.google.com/p/mosh-scheme/
On Wed, Apr 8, 2009 at 1:15 PM, Itagaki Takahiro
<itagaki.takahiro@oss.ntt.co.jp> wrote:
>
> higepon <higepon@gmail.com> wrote:
>
>> As a user of database, I think contrib/lo is not the best way.
>> Because it's not a part of core PostgreSQL, users may forget to use them.
>> Or it is a little messy to use.
>> So I think we need to implement *Auto* delete functionality in PostgreSQL core.
>
> (It would be a rare case, but) A large object might be referenced
> by two or more rows because LO interface is split into two steps;
> allocating oid and storing data for it. The oid could be stored in
> two or more places and auto deletion would break such usecases.
>
> BTW, bytea and TOASTing would works perfectly as you expected.
> Why don't you use bytea instead of large objects? In other words,
> what you want actually is not LO improvement but efficient TOASTing, no?
>
> Regards,
> ---
> ITAGAKI Takahiro
> NTT Open Source Software Center
>
>
>
