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!
