Thomas Kellerer wrote:
Sameer Mahajan, 19.02.2009 07:38:
* Shared memory based connectivity: As such postgres has client
- server model. The TCP-IP nature of its connectivity further adds to
the latency of this communication. It will be nice to have a shared
memory based connectivity between libpq front end and the back end.
I have never worked with an application that ran on the same server as
the database.
Application server (e.g. for webapps) and database server are almost
always on different machines (even more so for client/server
applications).
So an application in production system doesn't really benefit from
this. It will always have to go through tcp.
Or am I missing something?
This isn't all that unusual when you talk about non-traditional
client-server applications. For example, when you install a desktop app
(such as ACT, Peachtree, Quickbooks, etc.) that works in a "standalone"
mode without a dedicated server. In such cases the stand-alone app
installs the database server locally (and its started and stopped with
the app - or just started and left running and the app connects
locally), but when it operates in a workgroup setting a centralized
database would be used.
Basically, if you try to use PostgreSQL as a local data store for a
desktop app, you'll likely want to use socket connections.
Unfortunately, if its a windows app, I'm not sure if there is much
benefit to using a socket over tcp/ip . I thought at one point there
was an issue with the windows socket implementation that made it less
than ideal...but that might have been a long time ago....does anyone know?
--
Chander Ganesan
Open Technology Group, Inc.
One Copley Parkway, Suite 210
Morrisville, NC 27560
919-463-0999/877-258-8987
http://www.otg-nc.com
Ask me about expert PostgreSQL, PostGIS & other Open Source Training!
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
