Re: Embedded SQL inherently faster than others?

> -----Original Message-----
> From: Rob [mailto:pgadmin(at)itsbeen(dot)sent(dot)com]
> Sent: Wednesday, May 05, 2004 12:25 PM
> To: pgsql-general(at)postgresql(dot)org
> Subject: Re: [GENERAL] Embedded SQL inherently faster than others?
>
>
> Dann Corbit snip:
> >>-----Original Message-----
> >>From: Kevin [mailto:leinfidel(at)netscape(dot)net]
> >>Sent: Tuesday, May 04, 2004 10:18 AM
> >>To: pgsql-general(at)postgresql(dot)org
> >>Subject: [GENERAL] Embedded SQL inherently faster than others?
> >>
> >>
> >>Hello,
> >>
> >
> >>I'm looking for absolute maximum database result speed and if
> >>that means writing something in C and embedded SQL, versus
> >>Perl using DBI or whatever...that's fine.
> >
> >
> > Benchmark your application. 90% of the time will be in ten percent
> > of...
>
> And if you don't have a method for reusing connections or
> doing some connection pooling then for short running sql,
> much of the time will be spent on establishing a connection.

Connection time is never a problem for me. So (as usual) YMMV.

Besides connection pooling, other obvious answers would include reusing
the existing connections for queries.

Consider a web server. If the people who are attaching do not need
special rights to data (e.g. all users of the application are at the
same level) then the web server can launch a collection of database
engines and maintain a thread pool for attaching users that compete for
those resources.

There is always a way around performance problems. And why all the
sudden concern about connection times? Are lots of people actually
having a problem with it or is it some angels dancing on the heads of
pins kind of a thing?