Hello all,
thanks a lot for your help so far. You all where right about the IDE drive is
somehow caching the data. See the test results below. I also get different
tps values every time I run pgbench on PC1 (between 300 and 80 tps for 100
transactions).
I don't think it's a good idea to
Tatsuo Ishii [EMAIL PROTECTED] writes:
Interesting. We (some Japanese companies including SRA OSS,
Inc. Japan) did some PG scalability testing using a Unisys's big 16
(physical) CPU machine and found PG scales up to 8 CPUs. However
beyond 8 CPU PG does not scale anymore. The result
From: Bruno Wolff III [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 12, 2006 8:54 PM
To: Medora Schauer
Cc: postgresql
Subject: Re: hyper slow after upgrade to 8.1.4
On Wed, Jul 12, 2006 at 15:41:14 -0500,
Medora Schauer [EMAIL PROTECTED] wrote:
I have just upgraded from 7.3.4 to
On Thu, Jul 13, 2006 at 08:22:46AM -0500, Medora Schauer wrote:
Can it be that the connection delay is because first an IPv6 socket is
trying to be established and when that fails an IPv4 socket is created?
A sniffer like tcpdump or ethereal might reveal why connecting is
so slow. The problem
Tatsuo Ishii [EMAIL PROTECTED] writes:
18% in s_lock is definitely bad :-(. Were you able to determine which
LWLock(s) are accounting for the contention?
Yes. We were interested in that too. Some people did addtional tests
to determin that. I don't have the report handy now. I will report
Tom Lane [EMAIL PROTECTED] writes:
Steve McWilliams [EMAIL PROTECTED] writes:
I notice that non-printables in bytea values are being spit out by pg_dump
using escaped octet sequences even when the -Fc option is present
specifying use of the custom binary output format rather than plain
Michael Fuhr [EMAIL PROTECTED] writes:
On Thu, Jul 13, 2006 at 08:22:46AM -0500, Medora Schauer wrote:
Can it be that the connection delay is because first an IPv6 socket is
trying to be established and when that fails an IPv4 socket is created?
A sniffer like tcpdump or ethereal might reveal
Greg Stark [EMAIL PROTECTED] writes:
Didn't byteas used to get printed as hex?
No, not that I recall. I don't have anything older than 7.0 running,
but it behaves the same as now:
play= select 'xyz\\001'::bytea;
?column?
--
xyz\001
(1 row)
play=
regards, tom
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 13, 2006 11:12 AM
Michael Fuhr [EMAIL PROTECTED] writes:
On Thu, Jul 13, 2006 at 08:22:46AM -0500, Medora Schauer wrote:
Can it be that the connection delay is because first an IPv6 socket
is
trying to be established and when
[EMAIL PROTECTED] writes:
... is quite reasonable.The table has 1.000.000 rows (17.242 pages). From
pg_stat_get_blocks_fetched I can see that there were 102 page requests for
table. So all things seem to work great here!
But if I multiply the size of the table ten-times (10.000.000 rows -
Craig A. James wrote:
I'm back to my original question: How do you kill a runaway query
without bringing down the whole database? Is there really no answer to
this?
As others have mentioned, pg_cancel_backend(pid) will stop query
execution by backend process id 'pid'.
While this is
Thanks for your reply, Mark:
I'm back to my original question: How do you kill a runaway query
without bringing down the whole database? Is there really no answer
to this?
... if you actually want to disconnect a backend
process then there is nothing to let you do this remotely. I recently
Steinar H. Gunderson wrote:
On Wed, Jul 12, 2006 at 08:43:18AM -0700, Craig A. James wrote:
Then you killed the wrong backend...
No queries run in postmaster. They all run in postgres backends. The
postmaster does very little actual work, other than keeping track of
everybody else.
It turns out
Craig A. James [EMAIL PROTECTED] writes:
Bottom line is that I was expecting instant death with SIGTERM, but
instead got an agonizing, drawn out -- but safe -- death of the query.
What was the query exactly?
Our expectation is that all or at least most queries should respond to
SIGINT or
14 matches
Mail list logo
