Re: Important speed difference between a query and a

> Frederic Jolliton <fred-pg(at)jolliton(dot)com> writes:
>>> To "emulate" a parametred view, I created a function as follow:
>>>
>>> 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;
>
>> So, the query in the function is not using index but the exact same
>> query alone does !

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> But it's not the same query, is it? With "LIMIT $1" the planner can't
> know what the limit value is exactly, so it has to generate a plan that
> won't be too unreasonable for either a small or a large limit.

Ok. So the query is optimized once and not each time.. I understand
now.

But, since I "know" better that PostgreSQL that query must use index
in most of case, can I force in some manner the function when
declaring it to take this in account ? I suppose (not tested) that
setting enable_seqscan just before will probably do it, but what about
dump/restore of the database when recreating the function and keep
this "fix" automatically ?