From: | Rod Taylor <rbt(at)rbt(dot)ca> |
---|---|
To: | Wei Weng <wweng(at)kencast(dot)com> |
Cc: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, Chris Faulkner <chrisf(at)oramap(dot)com>, Pgsql-Performance <pgsql-performance(at)postgresql(dot)org>, Pgsql-Sql <pgsql-sql(at)postgresql(dot)org> |
Subject: | Re: sql performance and cache |
Date: | 2003-10-14 18:15:39 |
Message-ID: | 1066155338.63280.7.camel@jester |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance pgsql-sql |
> > Perhaps you are confusing it with the MySQL query cache?
> Is there plan on developing one (query cache)?
For the most part, prepared queries and cursors give you a greater
advantage due to their versatility -- both of which we do have.
In the cases where an actual cache is useful, the client application
could do it just as easily or temp tables can be used.
I suspect it would be implemented more as a caching proxy than as an
actual part of PostgreSQL, should someone really want this feature.
From | Date | Subject | |
---|---|---|---|
Next Message | Sean Chittenden | 2003-10-14 18:42:37 | Re: go for a script! / ex: PostgreSQL vs. MySQL |
Previous Message | Tom Lane | 2003-10-14 18:15:14 | Re: go for a script! / ex: PostgreSQL vs. MySQL |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2003-10-14 18:34:19 | Re: get diagnostics not supported by ecpg? |
Previous Message | Peter Eisentraut | 2003-10-14 18:13:11 | Re: security definer function |