Subject | Re: [Firebird-Architect] Global Temporary Tables |
---|---|
Author | Jim Starkey |
Post date | 2005-01-23T16:28:36Z |
Vlad Horsun wrote:
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. 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? Maybe
copying the blob isn't such a bad idea after all. 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.
> About blobsI think this is necessary, but I doubt it will be used often. There are
>
>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);
>
>
>
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. 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? Maybe
copying the blob isn't such a bad idea after all. 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.