From: | Thomas Swan <tswan(at)olemiss(dot)edu> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: BLOBs |
Date: | 2001-06-12 22:19:46 |
Message-ID: | 3B269582.5010701@olemiss.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian wrote:
>>Thomas Swan <tswan(at)olemiss(dot)edu> writes:
>>
>>>I know that BLOBs are on the TODO list, but I had an idea.
>>>
>>I think you just rediscovered TOAST.
>>
>
>We have TOAST and people want to keep large objects for performance. I
>think we could us an API that allows TOAST binary access and large
>object access using the same API, and hopefully an improved one.
>
I think I missed what I was trying to say in my original statement. I
think there's a way to use the existing API with performance benefits
left intact.
Take for example the table :
create table foo {
foo_id serial,
foo_name varchar(32),
foo_object BLOB,
);
On the insert statement "insert into foo (foo_name,foo_object) values
('My Object','{some escaped arbitrary string of binary data}');", flush
the {some escaped arbitrary string of binary data} to disk as a
temporary file. Then do the lo_import operation transparent to the user.
On a select, do the same thing (transparently) and return the data back
to user.
Personally, I like LO's being stored separately from the actual table.
From | Date | Subject | |
---|---|---|---|
Next Message | Reinoud van Leeuwen | 2001-06-12 22:47:42 | Re: Migration from FoxPro |
Previous Message | Bruce Momjian | 2001-06-12 20:31:26 | Re: Australian timezone configure option |