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
But for a large number, it probably doesn't exist on that table at all.
Thanks for the heads up.
In response to
pgsql-performance by date
|Next:||From: Dirk Lutzebäck||Date: 2004-09-29 15:55:45|
|Subject: why does explain analyze differ so much from estimated explain?|
|Previous:||From: Shea,Dan [CIS]||Date: 2004-09-29 14:44:12|
|Subject: Re: Interest in perf testing?|
pgsql-hackers-win32 by date
|Next:||From: Tom Lane||Date: 2004-09-29 16:18:13|
|Subject: Re: Poor Performance for large queries in functions |
|Previous:||From: Richard Huxton||Date: 2004-09-29 08:40:11|
|Subject: Re: [PERFORM] Poor Performance for large queries|