470,614 Members | 1,425 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 470,614 developers. It's quick & easy.

Unix domain instead of TCP socket connections with JDBC.

Using the org.postgresql.Driver JDBC driver is it possible to connect
to Postgres using a unix domain socket instead of a TCP socket (so you
don't have to start the postmaster with -i)? Using a TCP socket
instead of a unix socket seems to slow down requests that return large
result sets by a factor of 3 on the same machine. What's the point of
all the extra CPU overhead if you're on the same machine? A
high-volume server can really do without the extra overhead. Also, for
security reasons it would be slightly nicer to run Postgres without -i
just so there's one less port popping up when you port-scan.
Nov 11 '05 #1
4 5864
fr*********@yahoo.com (Alex Martinoff) writes:
... Using a TCP socket
instead of a unix socket seems to slow down requests that return large
result sets by a factor of 3 on the same machine.


Seems like a kernel bug to me. All modern TCP stacks have shortcuts for
local connections. What platform are you on exactly?

(BTW, this is not an argument against having JDBC support unix-socket
connections; I can see security reasons for that. But there should not
be performance reasons for it.)

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

Nov 11 '05 #2


On 7 Sep 2003, Alex Martinoff wrote:
Using the org.postgresql.Driver JDBC driver is it possible to connect
to Postgres using a unix domain socket instead of a TCP socket (so you
don't have to start the postmaster with -i)? Using a TCP socket
instead of a unix socket seems to slow down requests that return large
result sets by a factor of 3 on the same machine. What's the point of
all the extra CPU overhead if you're on the same machine? A
high-volume server can really do without the extra overhead. Also, for
security reasons it would be slightly nicer to run Postgres without -i
just so there's one less port popping up when you port-scan.


Java does not provide an API for dealing with unix sockets. It might
be possible to create such an interface via JNI, but I doubt you'll get
a whole lot of interest from the JDBC driver developers as the postgresql
JDBC driver is a Type IV (pure java) driver.

Is this factor of 3 difference in time the difference from running psql
over unix sockets vs tcp, or is it the difference between a Java client
and psql? If it's the latter you're not really doing an apples to apples
comparison.

Kris Jurka
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

Nov 11 '05 #3
The tomcat developers were working on a hybrid system, that would use
unix sockets via JNI for local connections, but I'm not sure what
happened to it. Or maybe they used a named pipe instead? I really
don't know.
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Nov 11 '05 #4
The tomcat developers were working on a hybrid system, that would use
unix sockets via JNI for local connections, but I'm not sure what
happened to it. Or maybe they used a named pipe instead? I really
don't know.
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Nov 11 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

7 posts views Thread by Gabriele Farina | last post: by
1 post views Thread by afalanga | last post: by
reply views Thread by Joseph Dionne | last post: by
1 post views Thread by Didatus | last post: by
9 posts views Thread by Phil Jenson | last post: by
2 posts views Thread by Torsten | last post: by
reply views Thread by Mangabasi | last post: by
1 post views Thread by wsguglielmetti | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.