Richard Huxton wrote:
John Meinel wrote:

So notice that when doing the actual select it is able to do the index query. But for some reason with a prepared statement, it is not able to do it.

Any ideas?

In the index-using example, PG knows the value you are comparing to. So, it can make a better estimate of how many rows will be returned. With the prepared/compiled version it has to come up with a plan that makes sense for any value.

If you look back at the explain output you'll see PG is guessing 181,923 rows will match with the prepared query but only 1 for the second query. If in fact you returned that many rows, you wouldn't want to use the index - it would mean fetching values twice.

The only work-around if you are using plpgsql functions is to use EXECUTE to make sure your queries are planned for each value provided.

I suppose that make sense. If the number was small (< 100) then there probably would be a lot of responses. Because the tproject table is all small integers.

But for a large number, it probably doesn't exist on that table at all.

Thanks for the heads up.


Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to