> > About blobs
> >
> >ibase.h :
> >
> >#define isc_bpb_storage 7
> >
> >#define isc_bpb_storage_main 0
> >#define isc_bpb_storage_temp 2
> >
> >
> >char bpb[] = {isc_bpb_version1, isc_bpb_storage, isc_bpb_storage_main};
> >isc_create_blob2(status, &db_handle, &trans, &blob_handle, &blob_id, sizeof(bpb), bpb);
> >
> >
> >
> I think this is necessary, but I doubt it will be used often. There are
> a couple of other approaches. One is to copy blobs from permanent to
> temporary space during blob assignment to a temporary table, which seems
> like a lot of work for very little gain. The other is just keep track
> of temporary blobs allocated in permanent space and release the pages at
> an appropriate time.

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.

> 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;
};

struct win is a key player and changed also:

was
struct win {
SLONG win_page;


stay
struct win {
PageNumber win_page;


Each relation and blob has its own pageSpaceID.

> Maybe copying the blob isn't such a bad idea after all.

If we can avoid it - why not ?

> 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 ;)


Regards,
Vlad