Hi,
Consider the where-clauses:
WHERE lower(col) LIKE 'abc';
WHERE lower(col) LIKE 'abc%';
these will both use a b-tree functional index in lower(col) if one exists.
The clause
WHERE lower(col) LIKE '%abc';
can't use the index as you would expect, because of the wildcard at the
front (as
On Thu, Jun 23, 2005 at 11:55:35AM -0700, Josh Berkus wrote:
Bruno,
I remember some discussion about delaying planning until the first
actual query so that planning could use actual parameters to do
the planning. If you really want to have it check the parameters
every time, I think you
Of course, I could modify the application and send different SQL
depending on which case we're in or just constructing a query with a
literal each time, but is there a way to add a hint to the SQL that
would cause the query to be re-planned if it's a case that could use the
index? Or
On Thu, Jun 23, 2005 at 10:33:18 +0200,
Kurt De Grave [EMAIL PROTECTED] wrote:
Now it's tempting to dream of some mechanism that could make the
database consider
replanning the query automatically once it knows the parameter, or
choose from
a set of plans depending on the parameter. In
Bruno,
I remember some discussion about delaying planning until the first
actual query so that planning could use actual parameters to do
the planning. If you really want to have it check the parameters
every time, I think you will need to replan every time. I don't
know if there is a way to
Hi,
Consider the where-clauses:
WHERE lower(col) LIKE 'abc';
WHERE lower(col) LIKE 'abc%';
these will both use a b-tree functional index in lower(col) if one exists.
The clause
WHERE lower(col) LIKE '%abc';
can't use the index as you would expect, because of the wildcard at the
front. Thus,
Kurt,
Of course, I could modify the application and send different SQL
depending on which case we're in or just constructing a query with a
literal each time, but is there a way to add a hint to the SQL that
would cause the query to be re-planned if it's a case that could use the
index? Or
