Thread: Re: [GENERAL] Re: Large Objects
|1) What exactly do you mean with 'view'? | A large object is referenced by its OID (objectID). You just can dump |the object to a file and view the file. I read somewhere (a while back) that postgres internally stores large objects as single files on the filesystem. Is this still the case? If it is is there anywork being done to change this? Thanks...james
On Fri, 20 Nov 1998, James Oden wrote: > |1) What exactly do you mean with 'view'? > | A large object is referenced by its OID (objectID). You just can dump > |the object to a file and view the file. > I read somewhere (a while back) that postgres internally stores large > objects as single files on the filesystem. Is this still the case? If it > is is there anywork being done to change this? Yes, it still is a seperate file... seems to be a straightforward approach. What's wrong with that? Jeroen Jeroen Schaap.............I was dreaming of guitarnotes that would irritate Homepage: <http://rulffh.medfac.leidenuniv.nl>..| ^|^ |...an executive kind Keywords: Guitars, Linux, Mac and SCN...........\_`-'_/..............of guy Tel: (0)71-5276811................................| |...........Frank Zappa
On Fri, 20 Nov 1998, Jeroen Schaap wrote:
> On Fri, 20 Nov 1998, James Oden wrote:
>
> > |1) What exactly do you mean with 'view'?
> > | A large object is referenced by its OID (objectID). You just can dump
> > |the object to a file and view the file.
> > I read somewhere (a while back) that postgres internally stores large
> > objects as single files on the filesystem. Is this still the case? If it
> > is is there anywork being done to change this?
>
> Yes, it still is a seperate file... seems to be a straightforward
> approach. What's wrong with that?
Unless it's changed in the last few days, they are stored as two files, a
table xinv???? & an index xinx???? (where ???? is the oid of the object).
There was talk of having an alternative system of storing large objects,
as the current scheme is not that efficient in terms of disk space used.
--
Peter T Mount peter@retep.org.uk
Main Homepage: http://www.retep.org.uk
PostgreSQL JDBC Faq: http://www.retep.org.uk/postgres
Java PDF Generator: http://www.retep.org.uk/pdf
On Fri, 20 Nov 1998, Jeroen Schaap wrote:
// Yes, it still is a seperate file... seems to be a straightforward
// approach. What's wrong with that?
There are two problems:
1) It's actually two files, which eats up a lot of inodes to store
the records, this is bad, and counter-intuitive.
2) They're all stored in the same directory, which happens to be
the same directory as the rest of the data, which means file
access will get slower as you add BLOBs.
One would be OK if it were one file per BLOB, though it'd be nicer
to manage it in files for blocks/pages instead of individual files.
Two should be fixed. At *least* have a BLOB subdirectory, but
preferebly, if you're going to be doing files like this, something like:
/usr/local/pgsql/data/base/dbname/blob/xx/yy/oid
where xx and yy come from a simple hash of the oid.
--
SA, beyond.com The world is watching America,
pub 1024/3CAE01D5 1994/11/03 Dustin Sallings <dustin@spy.net>
| Key fingerprint = 87 02 57 08 02 D0 DA D6 C8 0F 3E 65 51 98 D8 BE
L________________________________________ and America is watching TV. __
> On Fri, 20 Nov 1998, Jeroen Schaap wrote: > > // Yes, it still is a seperate file... seems to be a straightforward > // approach. What's wrong with that? > > There are two problems: > > 1) It's actually two files, which eats up a lot of inodes to store > the records, this is bad, and counter-intuitive. > 2) They're all stored in the same directory, which happens to be > the same directory as the rest of the data, which means file > access will get slower as you add BLOBs. > > One would be OK if it were one file per BLOB, though it'd be nicer > to manage it in files for blocks/pages instead of individual files. > > Two should be fixed. At *least* have a BLOB subdirectory, but > preferebly, if you're going to be doing files like this, something like: > > /usr/local/pgsql/data/base/dbname/blob/xx/yy/oid > > where xx and yy come from a simple hash of the oid. Yes, I plan to change it. The old code required it to be called inv*, but the new code uses a new large object flag, so in the future, I can rename the files, and move them into a subdirectory perhaps, and the code will still work. I have to wait for the old code using the old libpq to expire, perhaps after 6.5. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026