Re: [Info-Ingres] Insert performance (was "Sun buys MySQL")
- From: "On Web" <a@xxxxx>
- Date: Sun, 10 Feb 2008 22:01:06 GMT
"Karl Schendel" <schendel@xxxxxxxxxxxxxx> wrote in message
news:mailman.20.1202666609.2607.info-ingres@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Feb 10, 2008, at 5:49 PM, On Web wrote:
Good point Jürgen, after 30 seconds of thought it seems to me that
there's no reason why the database engine can't cache query plans as a
matter of course in memory. These days it's not as if servers are
strapped for memory. The plans could be invalidated on updates to the
schema or other significant changes.
Just why do we really need a repeated keyword?
You'd be surprised at how easy it is to run a server off the end of
13 gigs or so of memory. I do it all the time! :-)
But realistically, no, repeated isn't strictly needed. Detecting
identical queries, and allowing for DDL and similar changes,
is not nearly as trivial as you'd like to think, but it's
doable, I'm sure.
In Java I used to trap front-end queries en-route to the database (via jdbc)
and check them against queries that had already been performed - a straight
match, nothing fancy. As well as the query text, I knew which tables were
involved. If I had a match I would then pass back the same result set that
had been returned previously (without querying the database). I would only
cache a limited number of queries and would cull the least recently used
ones to make way for new entries when the cache was full.
If the user asked the application to update the database, any cached query
information involving those tables would be removed from the application
cache so that future queries would pick up updated results from the
database. It boosted performance enormously, especially for tables of
(mostly) static data.
This was only possible because only that particular application would be
manipulating the data in question, so there was no danger of data changing
behind the scenes. But it's not really that hard and I'm sure that a similar
mechanism could be embedded in the ingres query mechanism.
Paul
Karl
.
- Follow-Ups:
- Re: [Info-Ingres] Insert performance (was "Sun buys MySQL")
- From: Betty & Karl Schendel
- Re: [Info-Ingres] Insert performance (was "Sun buys MySQL")
- References:
- Re: [Info-Ingres] Insert performance (was "Sun buys MySQL")
- From: Karl Schendel
- Re: [Info-Ingres] Insert performance (was "Sun buys MySQL")
- Prev by Date: Re: [Info-Ingres] Insert performance (was "Sun buys MySQL")
- Next by Date: Re: [Info-Ingres] Problems Installing Ingres 2006 R2 on SuSE 10
- Previous by thread: Re: [Info-Ingres] Insert performance (was "Sun buys MySQL")
- Next by thread: Re: [Info-Ingres] Insert performance (was "Sun buys MySQL")
- Index(es):
Relevant Pages
|
