Re: Important speed difference between a query and a
От | Hannu Krosing |
---|---|
Тема | Re: Important speed difference between a query and a |
Дата | |
Msg-id | 1051254090.2997.3.camel@fuji.krosing.net обсуждение исходный текст |
Ответ на | Re: Important speed difference between a query and a (Frederic Jolliton <fred-pg@jolliton.com>) |
Список | pgsql-performance |
Frederic Jolliton kirjutas N, 24.04.2003 kell 19:33: > > 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 ? You could define two functions - one for small sets with constant LIMITs (maybe 50) in UNION parts, and another with $1. Then use accordingly. > 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 ? ------------- Hannu
В списке pgsql-performance по дате отправления: