Re: Important speed difference between a query and a - Mailing list pgsql-performance

From Frederic Jolliton
Subject Re: Important speed difference between a query and a
Date
Msg-id 86bryvsvmo.fsf@mau.localdomain
Whole thread Raw
In response to Re: Important speed difference between a query and a  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Important speed difference between a query and a
List pgsql-performance
> Frederic Jolliton <fred-pg@jolliton.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@sss.pgh.pa.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 ?


pgsql-performance by date:

Previous
From: Stephan Szabo
Date:
Subject: Re: Important speed difference between a query and a
Next
From: Frederic Jolliton
Date:
Subject: Re: Important speed difference between a query and a