Tom,
> AFAICS, the whole point of EXECUTE in plpgsql is that it doesn't take
> any shortcuts, and so the answer to Josh's question can only be "don't
> use EXECUTE"...
Yeah, that's what I thought, I was just hoping for some low-hanging fruit.
--
-Josh Berkus
Aglio Database Solutions
San Franc
Joe Conway <[EMAIL PROTECTED]> writes:
> Josh Berkus wrote:
>> While we're on the topic, anyone know any good ways to speed up EXECUTE
>> statements in PL/pgSQL functions?
> Never tried it, but is it possible to use a prepared statement inside a
> PL/pgSQL function?
You could probably EXECUTE p
Joe,
> Never tried it, but is it possible to use a prepared statement inside a
> PL/pgSQL function? In any case, you can in other PLs. And with library
> preloading (starting in 7.4), the first call to other PLs is similar to
> that of PL/pgSQL. See:
>http://archives.postgresql.org/pgsql-pa
Josh Berkus wrote:
Yes, I believe so (well, actually the optimizer). An inlined SQL
function ends up behaving like a macro that expands at run time and is
therefore quite fast -- no function call overhead at all.
... but only in 7.4. In 7.2 and I think in 7.3 this was not implemented.
Yeah, tha
Joe,
> Yes, I believe so (well, actually the optimizer). An inlined SQL
> function ends up behaving like a macro that expands at run time and is
> therefore quite fast -- no function call overhead at all.
... but only in 7.4. In 7.2 and I think in 7.3 this was not implemented.
While we're on
Richard Huxton wrote:
On Monday 20 October 2003 18:24, Joe Conway wrote:
This question gets even more complex in 7.4, where many simple SQL
functions will get inlined, and library preloading is available to speed
that first PL/pgSQL call.
What will be the effects of inlining? Does it mean the plann
On Monday 20 October 2003 18:24, Joe Conway wrote:
> Richard Huxton wrote:
> > So - gain by not re-planning on every call, but maybe lose because your
> > plan is not so precise.
> >
> > Of course, any queries you build dynamically and run via EXECUTE will
> > have to be planned each time.
>
> This
Richard Huxton wrote:
So - gain by not re-planning on every call, but maybe lose because your plan
is not so precise.
Of course, any queries you build dynamically and run via EXECUTE will have to
be planned each time.
This question gets even more complex in 7.4, where many simple SQL
functions
On Monday 20 October 2003 16:36, Michael Pohl wrote:
> On Sun, 19 Oct 2003, Christopher Browne wrote:
> > The world rejoiced as [EMAIL PROTECTED] ("George A.J") wrote:
> > > i am converting an MSSQL database to Postgres. there is a lot of
> > > procedures to convert.
> > >
> > > which language is b
On Sun, 19 Oct 2003, Christopher Browne wrote:
> The world rejoiced as [EMAIL PROTECTED] ("George A.J") wrote:
> > i am converting an MSSQL database to Postgres. there is a lot of
> > procedures to convert.
> >
> > which language is best for functions, SQL or plpgsql.
> >
> > which is faster . i a
George,
> i am converting an MSSQL database to Postgres. there is a lot of procedures
> to convert.
>
> which language is best for functions, SQL or plpgsql.
If you're porting from T-SQL, you should use PL/pgSQL. However, you will have
to re-code many of your procedures by hand, as T-SQL and PL
The world rejoiced as [EMAIL PROTECTED] ("George A.J") wrote:
> i am converting an MSSQL database to Postgres. there is a lot of procedures to
> convert.
>
> which language is best for functions, SQL or plpgsql.
>
> which is faster . i am using postgres 7.3.2
Hmm? This doesn't seem to make much
12 matches
Mail list logo
