have to balance a limited budget, room for
future performance growth, and current system requirements. Trust me it
isn't easy.
Juan
-Original Message-
From: Josh Berkus [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 06, 2006 2:57 AM
To: pgsql-performance@postgresql.org
Cc: J
oming connections. I have this server available for
sixty days so I may as well explore the performance of postgresql on it.
Thanks,
Juan
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Luke
Lonergan
Sent: Wednesday, April 05, 2006 5:37 PM
To: Juan Casero (F
To: pgsql-performance@postgresql.org
Cc: Juan Casero (FL FLC); Luke Lonergan
Subject: Re: [PERFORM] Sun Fire T2000 and PostgreSQL 8.1.3
Juan,
> When I hit
> this pgsql on this laptop with a large query I can see the load spike
> up really high on both of my virtual processors. Whatever, p
the code.
Thanks,
Juan
-Original Message-
From: Luke Lonergan [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 05, 2006 5:37 PM
To: Juan Casero (FL FLC); pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Sun Fire T2000 and PostgreSQL 8.1.3
Juan,
On 4/5/06 1:54 PM, "Juan C
this question.
Thanks,
Juan
-Original Message-
From: Luke Lonergan [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 05, 2006 4:43 PM
To: Juan Casero (FL FLC); pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Sun Fire T2000 and PostgreSQL 8.1.3
Juan,
On 4/5/06 11:12 AM, "J
Greetings -
I am testing a Sun
Microsystems Sun Fire T2000 demo server at our company. I want to
know if anyone here has any experience with this hardware and postgresql
8.1.3. I installed the copy of postgresql 8.1.3 from blastwave.org onto
this demo box and loaded our production datab
. Any thoughts?
Thanks,
Juan
On Thursday 22 December 2005 22:12, David Lang wrote:
> On Wed, 21 Dec 2005, Juan Casero wrote:
> > Date: Wed, 21 Dec 2005 22:31:54 -0500
> > From: Juan Casero <[EMAIL PROTECTED]>
> > To: pgsql-performance@postgresql.org
> > Subje
Agreed. I have a 13 million row table that gets a 100,000 new records every
week. There are six indexes on this table. Right about the time when it
reached the 10 million row mark updating the table with new records started
to take many hours if I left the indexes in place during the update
kernel.
Would you agree this will probably yield the best performance?I know it
depends alot on the system but for now this database is about 20 gigabytes.
Not too large right now but it may grow 5x in the next year.
Thanks,
Juan
On Wednesday 21 December 2005 22:09, Juan Casero wrote
still going. The p4 has
1.3 Gigs of shared memory allocated to postgresql. How about them apples?
Thanks,
Juan
On Wednesday 21 December 2005 18:57, William Yu wrote:
> Juan Casero wrote:
> > Can you elaborate on the reasons the opteron is better than the Xeon when
> > it comes to
Can you elaborate on the reasons the opteron is better than the Xeon when it
comes to disk io? I have a PostgreSQL 7.4.8 box running a DSS. One of our
tables is about 13 million rows. I had a number of queries against this
table that used innner joins on 5 or 6 tables including the 13 mill
Guys -
Help me out here as I try to understand this benchmark. What is the Sun
hardware and operating system we are talking about here and what is the intel
hardware and operating system? What was the Sun version of PostgreSQL
compiled with? Gcc on Solaris (assuming sparc) or Sun studio? W
Marlowe wrote:
> From: [EMAIL PROTECTED] on behalf of Juan Casero
>
> QUOTE:
>
> Hi -
>
>
> Can anyone tell me how well PostgreSQL 8.x performs on the new Sun
> Ultrasparc T1 processor and architecture on Solaris 10? I have a custom
> built retail sales reporting that I d
Hi -
Can anyone tell me how well PostgreSQL 8.x performs on the new Sun Ultrasparc
T1 processor and architecture on Solaris 10? I have a custom built retail
sales reporting that I developed using PostgreSQL 7.48 and PHP on a Fedora
Core 3 intel box. I want to scale this application upwards to
14 matches
Mail list logo
