I am working on a system that uses postgresql 7.4.2 (can't change that
until 8.1 goes stable). Just figured out that there are about 285,000
connections created over about 11 hours every day. That averages out to
about 7.2 connections per second.
Is that a lot? I've never seen that many.
--
Bruce Momjian wrote:
Agha Asif Raza wrote:
Is there any MS-SQL Server like 'Profiler' available for PostgreSQL? A
profiler is a tool that monitors the database server and outputs a detailed
trace of all the transactions/queries that are executed on a database during
a specified period of
On Thu, 2005-07-14 at 00:19 -0700, Relaxin wrote:
Before I ask, I don't want to start a war.
Can someone here give me an honest opinion of how PostgresSQL (PG) is better
than Firebird on Windows?
A colleague of mine has made some benchmarks using those two:
I ran pgbench with a scale factor of 1000 and a total of 100,000
transactions per run. I varied the number of clients between 10 and
100. It appears from my test JFS is much faster than both ext3 and XFS
for this workload. JFS and XFS were made with the mkfs defaults. ext3
was made with -T
Jeffrey W. Baker [EMAIL PROTECTED] writes:
On Fri, 2005-07-15 at 00:00 -0700, Karim Nassar wrote:
I am working on a system that uses postgresql 7.4.2 (can't change that
until 8.1 goes stable). Just figured out that there are about 285,000
connections created over about 11 hours every day. That
On Jul 14, 2005, at 10:12 PM, John A Meinel wrote:
My biggest question is why the planner things the Nested Loop would be
so expensive.
Have you tuned any of the parameters? It seems like something is
out of
whack. (cpu_tuple_cost, random_page_cost, etc...)
here's some of my
On Jul 15, 2005, at 9:09 AM, Dan Harris wrote:
On Jul 14, 2005, at 10:12 PM, John A Meinel wrote:
My biggest question is why the planner things the Nested Loop
would be
so expensive.
Have you tuned any of the parameters? It seems like something is
out of
whack. (cpu_tuple_cost,
David Mitchell wrote:
If your table has got into this state, then vacuum analyze won't fix
it. You will have to do a vacuum full to get it back to normal, then
regularly vacuum (not full) to keep it in good condition. We vacuum
our critical tables every 10 minutes to keep them in good nick.
On Thu, Jul 14, 2005 at 16:29:58 -0600,
Dan Harris [EMAIL PROTECTED] wrote:
Ok, I tried this one. My ssh keeps getting cut off by a router
somewhere between me and the server due to inactivity timeouts, so
all I know is that both the select and explain analyze are taking
over an
Ok, I tried this one. My ssh keeps getting cut off by a router
somewhere between me and the server due to inactivity timeouts, so
all I know is that both the select and explain analyze are taking
over an hour to run. Here's the explain select for that one, since
that's the best I can get.
Ron Wills wrote:
Hello all
I'm running a postgres 7.4.5, on a dual 2.4Ghz Athlon, 1Gig RAM and
an 3Ware SATA raid.
2 drives?
4 drives?
8 drives?
RAID 1? 0? 10? 5?
Currently the database is only 16G with about 2
tables with 50+ row, one table 20+ row and a few small
tables. The
Hello all
I'm running a postgres 7.4.5, on a dual 2.4Ghz Athlon, 1Gig RAM and
an 3Ware SATA raid. Currently the database is only 16G with about 2
tables with 50+ row, one table 20+ row and a few small
tables. The larger tables get updated about every two hours. The
problem I having with
At Fri, 15 Jul 2005 13:45:07 -0700,
Joshua D. Drake wrote:
Ron Wills wrote:
Hello all
I'm running a postgres 7.4.5, on a dual 2.4Ghz Athlon, 1Gig RAM and
an 3Ware SATA raid.
2 drives?
4 drives?
8 drives?
3 drives raid 5. I don't believe it's the raid. I've tested this by
On Jul 15, 2005, at 2:39 PM, Ron Wills wrote:
Hello all
I'm running a postgres 7.4.5, on a dual 2.4Ghz Athlon, 1Gig RAM and
an 3Ware SATA raid.
Operating System? Which file system are you using? I was having a
similar problem just a few days ago and learned that ext3 was the
On Fri, Jul 15, 2005 at 03:04:35PM -0600, Ron Wills wrote:
Ron Wills wrote:
Hello all
I'm running a postgres 7.4.5, on a dual 2.4Ghz Athlon, 1Gig RAM and
an 3Ware SATA raid.
3 drives raid 5. I don't believe it's the raid. I've tested this by
moving the database to the
On Fri, 2005-07-15 at 15:04 -0600, Ron Wills wrote:
At Fri, 15 Jul 2005 13:45:07 -0700,
Joshua D. Drake wrote:
Ron Wills wrote:
Hello all
I'm running a postgres 7.4.5, on a dual 2.4Ghz Athlon, 1Gig RAM and
an 3Ware SATA raid.
2 drives?
4 drives?
8 drives?
3
At Fri, 15 Jul 2005 14:00:07 -0700,
Jeffrey W. Baker wrote:
On Fri, 2005-07-15 at 14:39 -0600, Ron Wills wrote:
Hello all
I'm running a postgres 7.4.5, on a dual 2.4Ghz Athlon, 1Gig RAM and
an 3Ware SATA raid. Currently the database is only 16G with about 2
tables with 50+ row,
At Fri, 15 Jul 2005 14:17:34 -0700,
Jeffrey W. Baker wrote:
On Fri, 2005-07-15 at 15:04 -0600, Ron Wills wrote:
At Fri, 15 Jul 2005 13:45:07 -0700,
Joshua D. Drake wrote:
Ron Wills wrote:
Hello all
I'm running a postgres 7.4.5, on a dual 2.4Ghz Athlon, 1Gig RAM and
On Fri, 2005-07-15 at 15:29 -0600, Ron Wills wrote:
Here's a bit of a dump of the system that should be useful.
Processors x2:
vendor_id : AuthenticAMD
cpu family : 6
model : 8
model name : AMD Athlon(tm) MP 2400+
stepping: 1
cpu MHz : 2000.474
At Fri, 15 Jul 2005 14:53:26 -0700,
Jeffrey W. Baker wrote:
On Fri, 2005-07-15 at 15:29 -0600, Ron Wills wrote:
Here's a bit of a dump of the system that should be useful.
Processors x2:
vendor_id : AuthenticAMD
cpu family : 6
model : 8
model name :
Dan Harris wrote:
On Jul 14, 2005, at 10:12 PM, John A Meinel wrote:
My biggest question is why the planner things the Nested Loop would be
so expensive.
Have you tuned any of the parameters? It seems like something is out of
whack. (cpu_tuple_cost, random_page_cost, etc...)
here's
21 matches
Mail list logo
