Re: parsed queries (cursors) cashing issues

I think the same way :). But as I mentioned in the first letter I'm not a C
guy. So I wonder why doesn't postgres store hashes for all queries and
misses parsing step if not needed like Oracle does?

On 8/3/07, Sibte Abbas <sibtay(at)gmail(dot)com> wrote:
>
> On 8/3/07, Sergey Moroz <smo(at)mgcp(dot)com> wrote:
> > No that is not I meant. The problem in Prepared statements is in that
> you
> > should determine SQL inside the function. I want to pass a query as a
> > parameter, as well as query parameters.
> > For example (I want to create a function like the following):
> >
> > select *
> > from exec_query(
> > /*query text => */ 'select f1, f2 from
> table
> > where f3 = $1' ,
> > /*param1 => */ 1::integer
> > )
> > as (f1 integer, f2 text)
> >
> > so function exec_query got a query text as parameter, query parameters,
> > executed it and returned result as SETOF. In case of such a query had
> been
> > executed at least once, prepare step should be excluded (stored
> execution
> > plan should be used).
> >
>
> In this case you need to store query text along with its plan name.
> This will allow you to simply execute the plan each time a previously
> parsed/planned query is executed.
>
> However storing raw queries can be a *very* expensive operation, not
> to mention the high cost of performing comparison on them. Due to the
> associated cost, I'll
> recommend using(and storing) hashes for query text.
>
> If I were you, i'll write the hash calculation and storage and
> retrieval functions in C and the top level function in Plpgsql.
>
> Hope that helps.
>
> regards,
> -- Sibte
>

--
Sincerely,
Sergey Moroz