From: | Neil Conway <neilc(at)samurai(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Scott Kirkwood <scottakirkwood(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Caching of Queries |
Date: | 2004-09-23 02:14:24 |
Message-ID: | 1095905663.22485.294.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Thu, 2004-09-23 at 05:59, Tom Lane wrote:
> I think this would allow the problems of cached plans to bite
> applications that were previously not subject to them :-(.
> An app that wants plan re-use can use PREPARE to identify the
> queries that are going to be re-executed.
I agree; if you want to do some work in this area, making improvements
to PREPARE would IMHO be the best bet. For example, some people have
talked about having PREPARE store queries in shared memory. Another idea
would be to improve the quality of the plan we generate at PREPARE time:
for instance you could generate 'n' plans for various combinations of
input parameters, and then choose the best query plan at EXECUTE time.
It's a difficult problem to solve, however (consider multiple parameters
to PREPARE, for example).
-Neil
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2004-09-23 03:41:21 | Re: NAS, SAN or any alternate solution ? |
Previous Message | Tom Lane | 2004-09-22 22:03:45 | Re: Fw: Infinite CPU loop due to field ::type casting, Take II :-) |