Thank you for explaining!
Now I understand, makes perfect sense! :-)
2010/2/22 Nikolas Everett :
> The planner knows that that particular date range is quite selective so it
> doesn't have to BitmapAnd two indexes together.
> The problem is that a prepared statement asks the db to plan the query
Actually, planner was smart in using a bitmap index scan in the prepared
query. Suppose you later EXECUTE that canned plan with a date range which
covers say half of the table : the indexscan would be a pretty bad choice
since it would have to access half the rows in the table in index orde
The planner knows that that particular date range is quite selective so it
doesn't have to BitmapAnd two indexes together.
The problem is that a prepared statement asks the db to plan the query
without knowing anything about the parameters. I think functions behave in
exactly the same way. Its k
Joel Jacobson writes:
> Hm, it is strange the query planner is using two different strategies
> for the same query?
They're not the same query. One plan is generic for any value of the
parameters, the other is chosen for specific values of those parameters.
In particular, the unparameterized q
db=# \d FlagValueAccountingTransactions
Table
"public.flagvalueaccountingtransactions"
Column| Type
|Modifiers
-+--
+
-
I cannot understand why the index is not being used when in the plpgsql
function?
I even tried to make a test function containing nothing more than the
single query. Still the index is not being used.
When running the same query in the sql prompt, the index is in use
though.
Please post t
Hi,
I am trying to make a select query in my plpgsql function to use an
index allowing an index scan instead of a seq scan.
When running the query in the sql prompt, it works fine, but
apparently the index is not used for the same query in the plpgsql
function.
The problem is not the d
