RE: [Firebird-devel] Caching for compiled statements

[Daniel R. <da...@ac...>]

At 31/05/2002 10:42 AM, Roman Rokytskyy wrote:
> > Here's an example of this usage being useful:
> >
> > Step 1:
> > User no.1 requests a query.  The query gets prepared and executed.  The
> > result gets placed into the cache.
> >
> > Step 2:
> > User no.2 requests the same query.  Check to see if the query results
> > are in the cache, if so retrieve from cache.  If not in cache,
> > prepare(check in
> > the statements cache first) and execute.
> >
> > This helps when dealing with large tables and a good number of
> > connections.  With small tables, it's not really needed.
>
>I would prefer to have something like materialized views in
>Oracle(http://www.oracle.com/oramag/oracle/99-Sep/index.html?59bob.html).
>You can have a internal cron job that will trigger synchronization of the
>view for example once a day.
>
>Then your complex select statements should be changed to query from
>materialized view, not from real tables.

I think both could be implemented, since one doesn't interfere with the 
other.  The concept that I was referring to was a dynamic concept, so it 
could be used in real-time.  The materialized view is useful for decision 
making environments, when most of the time where the required data is dated 
of yesterday or a few days already.  That is how I interpreted it on 
Oracle's web-site.  The aspect of it that would need some thought is how 
does the backup and restore deal with the materialized views, maybe on 
backup store the view like a normal view with a special flag and on restore 
perform the materialization of the view.


Daniel Rail
Senior System Engineer
ACCRA Group Inc. (www.accra.ca)
ACCRA Med Software Inc. (www.accramed.ca)