Hi. > <itagaki.takah...@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.takah...@oss.ntt.co.jp> wrote: > > higepon <hige...@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 > > > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
