I've mentioned this before in a previous discussion some months back, but
surely allowing stored procs to return result sets would alleviate this
problem. Then, the back end could use the stored proc mechanism to cache
those queries it felt were used often enough by simply creating a stored
proc for them (which is a brainless operation), alternatively, the developer
could optimise the application by writing certain stored procs into the
application.
Most commercial dbs allow this, and I'm surprised that more people don't see
this as a significant feature. I'm not exactly sure how they do this,
whether it's through the return of a cursor, or whether it's a special data
type that stores the rows: whatever, we can't be that far from being able to
hack something like this together.
MikeA
-----Original Message-----
From: Tom Lane
To: dougt@mugc.cc.monash.edu.au
Cc: pgsql-interfaces@postgreSQL.org
Sent: 99/12/02 05:21
Subject: Re: [INTERFACES] Slow join query optimisation?
Douglas Thomson <dougt@mugc.cc.monash.edu.au> writes:
> Is there any way to turn off the optimisation? Or perhaps some way to
> work out the optimal strategy once, and then provide this information
> directly?
Not at the moment. There's been some talk of caching query plans,
which would get the job done, but none of the current developers are
working on that now. It'll probably happen someday...
regards, tom lane
************
************
************
