Subject | Re: [Firebird-Architect] Global Temporary Tables |
---|---|
Author | Fabricio Araujo |
Post date | 2005-01-24T05:19:40Z |
On Sun, 23 Jan 2005 22:35:25 -0500, Jim Starkey wrote:
under the surface in the usual way, why don't do this: If the record
get copied to a temp table and in the record have a blob field
which have a blob pointer (or id or dbkey or what the hell you call it)
to the page the little monster is stored, what just copying the
pointer to the blob and forget that story of copying many MB from
here to there (as blobs don't have a defined limit in theory)? Just
point the blob temp field to the same place as the real blob
and if it (the temp field) get's updated so create another space
as this is another blob different from the first.
The if's about the original record (the one from this little petty
monster
got read):
1) If it got it's blob field updated ?
Just left the blob there and alloc a new blob page(s) for the new
monstrosity.
2) If it got deleted?
Pick your choices:
--> Mark the record as freed but NOT mark the blob page(s) freed until
the content
of temp vanishes
--> Copy the BLOB
If I am got it wrong, ok... But why we would trust that some developer
will not
do such a thing - following the policy of never trust what you don't
control, if you
have a choice.
>If I understand correctly all this stuff about blobs and how they work
>Vlad Horsun wrote:
>
>>>> About blobs
>>>>
>>>>
>>>>
>> If blob stored initially in one page space and assigned to relation from
>>another page space then we must copy blob into another page space and
>>release pages from first page space. Proposed bpb extension allow user
>>to avoid such copying - if user already know that blob will be assigned to
>>temporary table then he can point engine to allocate blob in temporary page
>>space at creation time.
>>
>>
>Yes, it would be nice if an application program were to declare that a
>blob is to go into temporary space, but given that the whole idea of
>temporary tables is that they are transparent to the application layer
>and tools, requiring applications and tools to take special actions just
>isn't going to fly. How are you going to do when somebody tries to
>assign the wrong type of blob, throw an error?
>
>The most common case is that data containing blobs will be copied from
>permanent tables into a temporary table. In this case, you have no
>choice but to copy the blob. So that leaves the far fetched case that
>somebody does inserts containing blobs into temporary tables that we're
>quibbling about. Can you come up with a scenario where somebody would
>ever do that? If not, why even worry about it -- copy the blob and get
>one with life.
under the surface in the usual way, why don't do this: If the record
get copied to a temp table and in the record have a blob field
which have a blob pointer (or id or dbkey or what the hell you call it)
to the page the little monster is stored, what just copying the
pointer to the blob and forget that story of copying many MB from
here to there (as blobs don't have a defined limit in theory)? Just
point the blob temp field to the same place as the real blob
and if it (the temp field) get's updated so create another space
as this is another blob different from the first.
The if's about the original record (the one from this little petty
monster
got read):
1) If it got it's blob field updated ?
Just left the blob there and alloc a new blob page(s) for the new
monstrosity.
2) If it got deleted?
Pick your choices:
--> Mark the record as freed but NOT mark the blob page(s) freed until
the content
of temp vanishes
--> Copy the BLOB
If I am got it wrong, ok... But why we would trust that some developer
will not
do such a thing - following the policy of never trust what you don't
control, if you
have a choice.