Magnus Hagander escribió:
Tom Lane wrote:
Linos writes:
Tom Lane escribió:
That's just weird --- ssl off should be ssl off no matter which knob you
use to turn it off. Are you sure it's really off in the slow connections?
Maybe i am missing something, i use the same command to connect to it
Tom Lane wrote:
> Linos writes:
>> Tom Lane escribió:
>>> That's just weird --- ssl off should be ssl off no matter which knob you
>>> use to turn it off. Are you sure it's really off in the slow connections?
>
>> Maybe i am missing something, i use the same command to connect to it
>> from loca
Linos writes:
> Tom Lane escribió:
>> That's just weird --- ssl off should be ssl off no matter which knob you
>> use to turn it off. Are you sure it's really off in the slow connections?
> Maybe i am missing something, i use the same command to connect to it
> from localhost "psql -d database -
Tom Lane escribió:
Linos writes:
Tom Lane escribió:
Does that number include connection startup overhead? (If it doesn't,
it'd be pretty strange.)
This difference it is from the runtime of the query, i get this with \timing
parameter in psql,
That's just weird --- ssl off should be ssl o
Linos writes:
> Tom Lane escribió:
>> Does that number include connection startup overhead? (If it doesn't,
>> it'd be pretty strange.)
> This difference it is from the runtime of the query, i get this with \timing
> parameter in psql,
That's just weird --- ssl off should be ssl off no matter
Tom Lane escribió:
Linos writes:
Hello, i have been having a problem like this in debian machines and i have
discovered that (almost in my case), the problem only arises when i am using
"ssl = true" in postgresql.conf although i am using clear tcp connections to
localhost to perform my query,
Linos writes:
> Hello, i have been having a problem like this in debian machines and i have
> discovered that (almost in my case), the problem only arises when i am using
> "ssl = true" in postgresql.conf although i am using clear tcp connections to
> localhost to perform my query, if i disable
Ross J. Reedstrom escribió:
Excellent. I'll take a look at this and report back here.
Ross
On Mon, Feb 23, 2009 at 04:17:00PM -0500, Tom Lane wrote:
"Ross J. Reedstrom" writes:
Summary: C client and large-object API python both send bits in
reasonable time, but I suspect there's still room
Excellent. I'll take a look at this and report back here.
Ross
On Mon, Feb 23, 2009 at 04:17:00PM -0500, Tom Lane wrote:
> "Ross J. Reedstrom" writes:
> > Summary: C client and large-object API python both send bits in
> > reasonable time, but I suspect there's still room for improvement in
> >
"Ross J. Reedstrom" writes:
> Summary: C client and large-object API python both send bits in
> reasonable time, but I suspect there's still room for improvement in
> libpq over TCP: I'm suspicious of the 6x difference. Detailed analysis
> will probably find it's all down to memory allocation and
On Thu, Feb 19, 2009 at 02:09:04PM +0100, PFC wrote:
>
> >python w/ psycopg (or psycopg2), which wraps libpq. Same results w/
> >either version.
>
> I've seen psycopg2 saturate a 100 Mbps ethernet connection (direct
> connection with crossover cable) between postgres server and client dur
[note: sending a message that's been sitting in 'drafts' since last week]
Summary: C client and large-object API python both send bits in
reasonable time, but I suspect there's still room for improvement in
libpq over TCP: I'm suspicious of the 6x difference. Detailed analysis
will probably find i
python w/ psycopg (or psycopg2), which wraps libpq. Same results w/
either version.
I've seen psycopg2 saturate a 100 Mbps ethernet connection (direct
connection with crossover cable) between postgres server and client during
a benchmark... I had to change the benchmark to not retrieve a
"Ross J. Reedstrom" writes:
> On Tue, Feb 17, 2009 at 12:20:02AM -0700, Rusty Conover wrote:
>>
>> Try running tests with ttcp to eliminate any PostgreSQL overhead and
>> find out the real bandwidth between the two machines. If its results
>> are also slow, you know the problem is TCP relat
On Tue, Feb 17, 2009 at 2:30 PM, Ross J. Reedstrom wrote:
> On Tue, Feb 17, 2009 at 03:14:55PM -0600, Ross J. Reedstrom wrote:
>> On Tue, Feb 17, 2009 at 01:59:55PM -0700, Rusty Conover wrote:
>> >
>> > What is the client software you're using? libpq?
>> >
>>
>> python w/ psycopg (or psycopg2), w
On Tue, Feb 17, 2009 at 03:14:55PM -0600, Ross J. Reedstrom wrote:
> On Tue, Feb 17, 2009 at 01:59:55PM -0700, Rusty Conover wrote:
> >
> > What is the client software you're using? libpq?
> >
>
> python w/ psycopg (or psycopg2), which wraps libpq. Same results w/
> either version.
>
It's not
On Tue, Feb 17, 2009 at 01:59:55PM -0700, Rusty Conover wrote:
>
> On Feb 17, 2009, at 1:04 PM, Ross J. Reedstrom wrote:
>
>
> What is the client software you're using? libpq?
>
python w/ psycopg (or psycopg2), which wraps libpq. Same results w/
either version.
I think I'll try network sniff
On Feb 17, 2009, at 1:04 PM, Ross J. Reedstrom wrote:
On Tue, Feb 17, 2009 at 12:20:02AM -0700, Rusty Conover wrote:
Try running tests with ttcp to eliminate any PostgreSQL overhead and
find out the real bandwidth between the two machines. If its results
are also slow, you know the problem
On Tue, Feb 17, 2009 at 12:20:02AM -0700, Rusty Conover wrote:
>
>
> Try running tests with ttcp to eliminate any PostgreSQL overhead and
> find out the real bandwidth between the two machines. If its results
> are also slow, you know the problem is TCP related and not PostgreSQL
> related
On Mon, Feb 16, 2009 at 11:04 PM, Ross J. Reedstrom wrote:
> Recently I've been working on improving the performance of a system that
> delivers files stored in postgresql as bytea data. I was surprised at
> just how much a penalty I find moving from a domain socket connection to
> a TCP connectio
On Tue, 17 Feb 2009, Rusty Conover wrote:
On Feb 17, 2009, at 12:04 AM, Ross J. Reedstrom wrote:
Recently I've been working on improving the performance of a system that
delivers files stored in postgresql as bytea data. I was surprised at
just how much a penalty I find moving from a domain so
On Feb 17, 2009, at 12:04 AM, Ross J. Reedstrom wrote:
Recently I've been working on improving the performance of a system
that
delivers files stored in postgresql as bytea data. I was surprised at
just how much a penalty I find moving from a domain socket
connection to
a TCP connection, ev
Recently I've been working on improving the performance of a system that
delivers files stored in postgresql as bytea data. I was surprised at
just how much a penalty I find moving from a domain socket connection to
a TCP connection, even localhost. For one particular 40MB file (nothing
outragous)
23 matches
Mail list logo
