Обсуждение: large objects
I'm working on a project where there is a need to store large texts in a database. I thought that postgres' large object are good for this. But one my fellow said me that current large object implementation is very unefficient. So having, say, several thousands of large objects is impractical. Is this true? Thanks in advance Aleksey -- Aleksey Demakov avd@gcom.ru
On 27 Jul 1998, Aleksey Demakov wrote: > > I'm working on a project where there is a need to store large texts in > a database. I thought that postgres' large object are good for this. > But one my fellow said me that current large object implementation is > very unefficient. So having, say, several thousands of large objects > is impractical. Is this true? The current implementation has a few problems. The object is stored using a table/index pair, and takes up more disk space than a single object. I haven't tried several thousand objects (yet). I'm working on large objects today, so I'll try to create a few thousand, and see what happens. -- Peter T Mount peter@retep.org.uk or petermount@earthling.net Main Homepage: http://www.retep.org.uk ************ Someday I may rebuild this signature completely ;-) ************ Work Homepage: http://www.maidstone.gov.uk Work EMail: peter@maidstone.gov.uk
Peter T Mount <peter@retep.org.uk> writes: > > The object is stored using a table/index pair, and takes up more disk > space than a single object. > How much more? And what about performance? In fact I don't need very large objects. 64k or even 32k will suffice. Could such not-so-large objects be implemented more effectively? It would be very nice to have a new postgres type for this. The 8k limit is very restrictive. What do postgres gurus think? Aleksey -- Aleksey Demakov avd@gcom.ru
On 27 Jul 1998, Aleksey Demakov wrote: > Peter T Mount <peter@retep.org.uk> writes: > > > > > The object is stored using a table/index pair, and takes up more disk > > space than a single object. > > > > How much more? And what about performance? > > In fact I don't need very large objects. 64k or even 32k will suffice. > Could such not-so-large objects be implemented more effectively? Anything larger than the page size (default is 8k, but can be larger) are a large object. The internals do alow for multiple storage managers, so it is possible to use other methods than the current "Inversion" scheme. We did have a posibility of a different manager, but I've heared nothing of it for some time now (pre 6.3 if memory serves)/ > It would be very nice to have a new postgres type for this. The 8k limit > is very restrictive. What do postgres gurus think? Part of the solution for the BLOB orphaning problem that JDBC & ODBC have requires a unique type 'lo' (required to differenciate between a generic oid, and a large object while vacuuming). However, for most cases, the existing lo interface is the only realistic way of handling them. -- Peter T Mount peter@retep.org.uk or petermount@earthling.net Main Homepage: http://www.retep.org.uk ************ Someday I may rebuild this signature completely ;-) ************ Work Homepage: http://www.maidstone.gov.uk Work EMail: peter@maidstone.gov.uk