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.

>>This does raise a tricky problem -- if you
>>implement (have implemented?) separate page spaces for temporary tables,
>>how do you keep track of what page number is in what space?
>>
>>
>
> I change internal page number representation.
>
>Page numbers was SLONG,
>
>stay
>
>class PageNumber
>{
>...
> SLONG pageNum;
> USHORT pageSpaceID;
>};
>
>

That's one approach, but one that is going to impact a huge amount of
code. An alternative is to recognized that page spaces are closed with
regard to page references, and make a formal PageSpace with methods to
the standard page operations (fetch (Netfrastructure uses page spaces
to implement repositories, so this is turf I've cross once.).

>>Unless something else
>>forced a full cache flush, in all likelihood the blob pages are still
>>sitting dirty in the case, so maybe the copy operation wouldn't cost any
>>actual I/O.
>>
>>
>
> Maybe. But not copying is always cheaper ;)
>
>
>

Sure, but if you only do it once in a hundred years, it doesn't make
much difference.


[Non-text portions of this message have been removed]