Re: Important speed difference between a query and a

> On Thu, 24 Apr 2003, Frederic Jolliton wrote:
>> > CREATE FUNCTION get_info (integer) RETURNS SETOF type_get_info
>> >     AS '...' <- here the query show below, where 'LIMIT $1' is used instead of 'LIMIT 10'
>> >     LANGUAGE sql;
>>
>> Setting enable_seqscan to off give same result speed between the query
>> and the function !
>>
>> So, the query in the function is not using index but the exact same
>> query alone does !
>>
>> Is there an explanation ?

Stephan Szabo <sszabo@megazone23.bigpanda.com> writes:
> My guess is that limit $1 is assuming a larger number of rows when
> planning the queries, large enough that it expects seqscan to be
> better (assuming the limit is what it expects).  It's probably not
> going to plan that query each time the function is called so it's
> not going to know whether you're calling with a small number (index
> scan may be better) or a large number (seq scan may be better).  For
> example, if you sent 100000, the index scan might be a loser.
>
> Perhaps plpgsql with EXECUTE would work better for that, although
> it's likely to have some general overhead.

The server is rather fast, and the query return 10 to 50 rows in most
case. So, this is probably a solution, even if it's not very
clean. (Well, I have to find an example to RETURN the result of
EXECUTE..)

But, what I don't understand is why enable_seqscan change something if
the query is already planed.

--
Frédéric Jolliton