Mailing List Archive


Back to the month index Back to the list index
Fernando Lozano (bl@riosoft.softex.br)
Wed, 15 Jan 1997 08:58:33 -0800 

Message-Id: <32DD0CB9.1930@riosoft.softex.br>
Date: Wed, 15 Jan 1997 08:58:33 -0800
From: Fernando Lozano <bl@riosoft.softex.br>
Subject: [mSQL] 2.0 - can it cache results?

Hi, David!

> > Then I think the best idea is to forget about the idea of temporary tables.
> > Implement the real ANSI "select into" clause and let the client-side worry
> > about dropping tables that may no longer be needed.
>
> But then that gives the worst of both worlds. The applications have to
> work out a way to try to generate a unique name for the table (as there
> may be many people running the same query at the same time). You can't
> just chuck a PID on the end as the app's could be running on various
> machines client/server.

I think it's not too bad. Each query I wanna cache will have it's name.
Before querying, my app can test if the "cache table" does exists. If
don't, execute a "select into" to create it. If an app modify data
selected by the query, it drops the "cache table".

Of course this will be impratical if the cached queries have so many
variations on its parameters (as each parameter would require a separate
cache table). But this case I guess any form of cache will be
impratical.

Comercial databases make a page cache from the database files (or
devices). Do you cache in RAM pages msql engine reads from disk? I think
a good caching and lots of RAM would be the best approach.

[]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!