From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | "Jeroen T(dot) Vermeulen" <jtv(at)xs4all(dot)nl> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Optimizing prepared statements |
Date: | 2006-09-03 20:56:51 |
Message-ID: | 877j0kwtws.fsf@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Jeroen T. Vermeulen" <jtv(at)xs4all(dot)nl> writes:
> Oh, sorry--I guess I haven't been too systematic about it. In the
> algorithm's current incarnation, ...
Thanks, that cleared things up enormously. I'm trying to figure how it would
react to some of the queries I've written in the past. In particular I'm
thinking of queries like
WHERE (? OR category = ?)
AND (? OR cost < ?)
AND (? OR description like ?||'%')
Where I then pass flags in from the application to indicate which search
constraints to apply. If it notices that most searches are for a particular
set of constraints it would be able to cache plans with the unused constraints
removed.
It would not however be able to notice that the last parameter never contains
a % and therefore can use an index scan.
I'm also wondering how this interacts with plan stability. Obviously the
direct effect is to throw out any chance of it. But in the long run they may
be two complementary sides of the same thing.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Gregory Stark | 2006-09-03 21:09:44 | Re: Concurrent connections in psql patch |
Previous Message | Peter Eisentraut | 2006-09-03 19:54:06 | Re: Getting a move on for 8.2 beta |