Thread: Large Object support for a DB FS

Large Object support for a DB FS

From
Bryan Bulten
Date:
Hello,

I am in a undergraduate course where we are doing some free-range
research.  I have selected to do a database file system for Linux built
on PostgreSQL, and using FUSE to expose a POSIX interface.

Originally I wanted to use large objects, but was turned away after
discovering that there is no truncate operation.

I then proceeded with implementing my own block-oriented data table
using bytea for storage.  This approach has been more flexible but has a
couple of draw-backs:

  1. To partially update a bytea field, I have to load it first,
     resulting in the overhead of an extra query.

  2. There is more overhead from the extra queries required to manage
     the block table.  The result is a large CPU hit for simple I/O.

So I'm now interested in implementing a lo_truncate operation, and
possibly a lo_size to go with it.  Does anyone have any advise on
alternatives, or how I could go about implementing this funcationality?


Thank-you.


(P.S. If you're interested in seeing the results of my research, e-mail
me off list, and I can send you the final report when complete :-) )

--
Bryan Bulten
http://www.bulten.ca/
http://wxnet.sourceforge.net/

Re: Large Object support for a DB FS

From
Karsten Hilbert
Date:
> I then proceeded with implementing my own block-oriented data table
> using bytea for storage.  This approach has been more flexible but has a
> couple of draw-backs:
>
>   1. To partially update a bytea field, I have to load it first,
>      resulting in the overhead of an extra query.
>
>   2. There is more overhead from the extra queries required to manage
>      the block table.  The result is a large CPU hit for simple I/O.
I'm sure there's quite a few people who'd be very delighted
if you chose to implement range-update/append support for bytea !

Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346