Re: [PERFORM] Poor Performance for large queries

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.

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBWs0iJdeBCYSNAAMRAu/PAJ9j450dzwsMWNUSlR4AvbirOzTlTQCgw4dM
069qTf5ZqQ2fRKsIt/ZkYcA=
=n+Tk
-----END PGP SIGNATURE-----