> -----Original Message----- > From: Rob [mailto:pgadmin@itsbeen.sent.com] > Sent: Wednesday, May 05, 2004 12:25 PM > To: pgsql-general@postgresql.org > Subject: Re: Embedded SQL inherently faster than others? > > > Dann Corbit snip: > >>-----Original Message----- > >>From: Kevin [mailto:leinfidel@netscape.net] > >>Sent: Tuesday, May 04, 2004 10:18 AM > >>To: pgsql-general@postgresql.org > >>Subject: 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? ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
