Back to the month index |
Back to the list index
|
Fernando Lozano (bl@riosoft.softex.br)
Fri, 10 Jan 1997 09:10:28 -0800
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
- Next message: by way of Projeto CINEMA BRASI: "Re: [mSQL] mSQL FAQ announcement (COMMENT)"
- Previous message: Fernando Lozano: "[mSQL] Persistent tables"
- In reply to: Gary Bickford: "Persistent tables (long) (Was: Re: [mSQL] Re: 2.0 - can it cache results?)"
Message-Id: <32D67804.7D2D@riosoft.softex.br> Date: Fri, 10 Jan 1997 09:10:28 -0800 From: Fernando Lozano <bl@riosoft.softex.br> Subject: [mSQL] 2.0 - can it cache results?Hi, Mark!
> >You bring up a good point though - how are the commercial dbms folks
> >handling this in their new web server packages?
>
> If we are talking about persistent temp tables (sounds like a pretty
> good oxymoron to me<g>), is that the same thing as a view under SQL?
No, it isn't. A view under standard SQL is basically a query, and is
usefull to give summary interfaces, to control who can see what data on
each table, and as a mean to hide changes to the schema.
> I guess the results of a view are not necessarily cached, however,
> just the query path -- but that probably would speed complex queries.
As far as I know, commercial data bases will cache only data and index
pages from the data base, like a disk cache will cache disk sectors.
They don't have the inteligence to discover that the same query has
already been proccessed.
They can save "access plans" (I missed the right jargon) to speed up
parsing and optimizing a query, but this can be done explicitly by the
app.
> It seems like having to build your own intermediate layer to cache
> results could end up recreating mSQL all over again
I think that a page cache would not be that difficult, and maybe Bambi
is already thinking about that.
> By the way, I'm not sure the commercial systems are all that
> intelligent yet -- I think a lot of them are just a front end into
> the normal query channels, and the performance is not so great in
> some cases.
They deppend on large amounts of RAM, as any caching system. :)
[]s, Fernando Lozano
Rio de Janeiro, Brasil
--------------------------------------------------------------------------
To remove yourself from the Mini SQL mailing list send a message containing
"unsubscribe" to "unsubscribe" to msql-list-request@bunyip.com. Send a message containing
"info msql-list" to majordomo@bunyip.com for info on monthly archives of
the list. For more help, mail owner-msql-list@bunyip.com NOT the msql-list!