| Subject | Re: [Firebird-Architect] Global Temporary Tables |
|---|---|
| Author | Jim Starkey |
| Post date | 2005-02-04T01:38:02Z |
Paulo Gaspar wrote:
wish) and, at least up to now, belong to a single record, so the
decision as to whether to garbage collect the blob or not is based
solely on the versions of that record that are to survive the garbage
collection. The engine has no other way to know that other records are
pointing to a blob, let alone how to find and analyse those records. In
the worst case, classic where a different process owns the temporary
table, there is absolute no way for one instance of the engine to even
know of the existence of instances of a temporary table.
These is an interesting on-going question of whether the benefits of
classic are worth the architecture costs and limitations. It's a good
question, and one we'll be coming back to time after time. The old
timers will say that classic is important for Unix systems. Sean, our
list neo-con, will argue that classic is important for Linux clusters.
Where is the truth? Hard to say because the little bugger won't hold still.
Personally, and reasonable people can (and will) differ, that temporary
tables aren't worth the tradeoff necessary to implement them. If we had
a ready and willing sponsor ready to part with cold cash, well, that
would be different. Right now, temporary tables are a fun
implementation question, but not of known value to anyone. I also
believe that throwing around the implementation questions are of great
value to the project, so let's not drop it.
> >>If I understand correctly all this stuff about blobs and how they workBlobs don't have reference counts (I'll blather in more detail if you
> >>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)?
> >>
> >The show stopper among the many reasons is that the source blob may be
> >garbage collected while the temporary table is holding a pointer to it.
>
>There seems to be something wrong about that picture.
>
>Shouldn't the blob ony be garbage collected AFTER or when the temporary
>table that refers to it is garabage collected to?
>
>
>
wish) and, at least up to now, belong to a single record, so the
decision as to whether to garbage collect the blob or not is based
solely on the versions of that record that are to survive the garbage
collection. The engine has no other way to know that other records are
pointing to a blob, let alone how to find and analyse those records. In
the worst case, classic where a different process owns the temporary
table, there is absolute no way for one instance of the engine to even
know of the existence of instances of a temporary table.
These is an interesting on-going question of whether the benefits of
classic are worth the architecture costs and limitations. It's a good
question, and one we'll be coming back to time after time. The old
timers will say that classic is important for Unix systems. Sean, our
list neo-con, will argue that classic is important for Linux clusters.
Where is the truth? Hard to say because the little bugger won't hold still.
Personally, and reasonable people can (and will) differ, that temporary
tables aren't worth the tradeoff necessary to implement them. If we had
a ready and willing sponsor ready to part with cold cash, well, that
would be different. Right now, temporary tables are a fun
implementation question, but not of known value to anyone. I also
believe that throwing around the implementation questions are of great
value to the project, so let's not drop it.