Re: eWeek Poll: Which database is most critical to your
От | Neil Conway |
---|---|
Тема | Re: eWeek Poll: Which database is most critical to your |
Дата | |
Msg-id | 1014766931.369.54.camel@jiro обсуждение исходный текст |
Ответ на | Re: eWeek Poll: Which database is most critical to your ("Dann Corbit" <DCorbit@connx.com>) |
Ответы |
Re: eWeek Poll: Which database is most critical to your
|
Список | pgsql-hackers |
On Tue, 2002-02-26 at 18:20, Dann Corbit wrote: > I don't see how it will do any good. There is no "prepare" in > Postgresql > and therefore you will simply be reexecuting the queries every time any > way. Also, parameter markers only work in embedded SQL and that is a > single tasking system. Perhaps I wasn't clear. The feature I'm proposing is this: When processing SELECT queries but before any real work has been done, lookup the query in a hash table. If it already exists, return the cached result. If it doesn't exist, execute the query and cache the result in the hash table. Optionally, we could not immediately cache the query, just increment a "frequency" counter stored in the hash table. If the counter goes above a certain constant, we decide that the query is worth caching, so we cache the full result in the hash table. When processing INSERTs, UPDATEs and DELETEs, check if the query would affect any of the tables for which we are maintaing this cache. If so, flush the cache. This ensures that we will never return invalid results. We could perhaps be fancy and keep stats on which columns our cached queries utilize and which columns the modifying query will affect, but that is unlikely to be an overall win. HOWEVER -- I don't see this feature as something that will appeal to, say, 75% of PgSQL users. If the table in question is being modified on a regular basis, or if a wide variety of queries are being issued, this cache isn't a good idea. Nevertheless, I think there are certainly some situations in which this cache is useful -- and furthermore, these kinds of "mostly read-only" situations are often where MySQL is chosen over PostgreSQL. Anyway, just putting this on the table -- if the consensus is that this isn't a very worthwhile feature, I won't bother with it. Cheers, Neil -- Neil Conway <neilconway@rogers.com> PGP Key ID: DB3C29FC
В списке pgsql-hackers по дате отправления: