pg.ddx.io pgsql-performance@postgresql.org mailing list archive
help / color / mirror / Atom feedPostgreSQL and Ultrasparc T1
22+ messages / 11 participants
[nested] [flat]
* PostgreSQL and Ultrasparc T1
@ 2005-12-18 16:35 Juan Casero <caseroj@comcast.net>
2005-12-18 17:12 ` Re: PostgreSQL and Ultrasparc T1 Christopher Petrilli <petrilli@gmail.com>
2005-12-19 07:21 ` Re: PostgreSQL and Ultrasparc T1 Luke Lonergan <llonergan@greenplum.com>
2005-12-20 19:34 ` Re: PostgreSQL and Ultrasparc T1 Jim C. Nasby <jnasby@pervasive.com>
0 siblings, 3 replies; 22+ messages in thread
From: Juan Casero @ 2005-12-18 16:35 UTC (permalink / raw)
To: pgsql-performance
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 handle a
database that might grow to a 100 GB. Our company is green mission conscious
now so I was hoping I could use that to convince management to consider a Sun
Ultrasparc T1 or T2 system provided that if I can get the best performance
out of it on PostgreSQL. So will newer versions of PostgreSQL (8.1.x) be
able to take of advantage of the multiple cores on a T1 or T2? I cannot
change the database and this will be a hard sell unless I can convince them
that the performance advantages are too good to pass up. The company is
moving in the Win32 direction and so I have to provide rock solid reasons for
why I want to use Solaris Sparc on a T1 or T2 server for this database
application instead of Windows on SQL Server.
Thanks,
Juan
-------------------------------------------------------
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: PostgreSQL and Ultrasparc T1
2005-12-18 16:35 PostgreSQL and Ultrasparc T1 Juan Casero <caseroj@comcast.net>
@ 2005-12-18 17:12 ` Christopher Petrilli <petrilli@gmail.com>
2 siblings, 0 replies; 22+ messages in thread
From: Christopher Petrilli @ 2005-12-18 17:12 UTC (permalink / raw)
To: Juan Casero <caseroj@comcast.net>; +Cc: pgsql-performance
On 12/18/05, Juan Casero <caseroj@comcast.net> wrote:
> 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 handle a
> database that might grow to a 100 GB. Our company is green mission conscious
> now so I was hoping I could use that to convince management to consider a Sun
> Ultrasparc T1 or T2 system provided that if I can get the best performance
> out of it on PostgreSQL. So will newer versions of PostgreSQL (8.1.x) be
> able to take of advantage of the multiple cores on a T1 or T2? I cannot
> change the database and this will be a hard sell unless I can convince them
> that the performance advantages are too good to pass up. The company is
> moving in the Win32 direction and so I have to provide rock solid reasons for
> why I want to use Solaris Sparc on a T1 or T2 server for this database
> application instead of Windows on SQL Server.
I do not know that anyone outside pilot orgs have received their
orders for the new T1 machines, so real world experience will not be
available yet. The big question is whether or not it manages the
processors only for threads (in which case Postgresql won't benefit
much) or for processes as well.
PostgreSQL takes a "process-parallel" approach to parallelism, not
thread-level. There are lost of historical reasons, but, that's just
hte way it is for now.
Chris
--
| Christopher Petrilli
| petrilli@gmail.com
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: PostgreSQL and Ultrasparc T1
2005-12-18 16:35 PostgreSQL and Ultrasparc T1 Juan Casero <caseroj@comcast.net>
@ 2005-12-19 07:21 ` Luke Lonergan <llonergan@greenplum.com>
2005-12-19 14:27 ` Re: PostgreSQL and Ultrasparc T1 Jignesh K. Shah <J.K.Shah@Sun.COM>
2 siblings, 1 reply; 22+ messages in thread
From: Luke Lonergan @ 2005-12-19 07:21 UTC (permalink / raw)
To: Juan Casero <caseroj@comcast.net>; pgsql-performance
Juan,
On 12/18/05 8:35 AM, "Juan Casero" <caseroj@comcast.net> wrote:
> 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 handle a
> database that might grow to a 100 GB. Our company is green mission conscious
> now so I was hoping I could use that to convince management to consider a Sun
> Ultrasparc T1 or T2 system provided that if I can get the best performance
> out of it on PostgreSQL. So will newer versions of PostgreSQL (8.1.x) be
> able to take of advantage of the multiple cores on a T1 or T2? I cannot
> change the database and this will be a hard sell unless I can convince them
> that the performance advantages are too good to pass up. The company is
> moving in the Win32 direction and so I have to provide rock solid reasons for
> why I want to use Solaris Sparc on a T1 or T2 server for this database
> application instead of Windows on SQL Server.
The Niagara CPUs are heavily multi-threaded and will require a lot of
parallelism to be exposed to them in order to be effective.
Until Sun makes niagara-based machines with lots of I/O channels, there
won't be much I/O parallelism available to match the CPU parallelism.
Bizgres MPP will use the process and I/O parallelism of these big SMP
machines and the version based on Postgres 8.1 will be out in February.
- Luke
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: PostgreSQL and Ultrasparc T1
2005-12-18 16:35 PostgreSQL and Ultrasparc T1 Juan Casero <caseroj@comcast.net>
2005-12-19 07:21 ` Re: PostgreSQL and Ultrasparc T1 Luke Lonergan <llonergan@greenplum.com>
@ 2005-12-19 14:27 ` Jignesh K. Shah <J.K.Shah@Sun.COM>
2005-12-19 17:30 ` Re: PostgreSQL and Ultrasparc T1 Luke Lonergan <llonergan@greenplum.com>
0 siblings, 1 reply; 22+ messages in thread
From: Jignesh K. Shah @ 2005-12-19 14:27 UTC (permalink / raw)
To: Luke Lonergan <llonergan@greenplum.com>; +Cc: Juan Casero <caseroj@comcast.net>; pgsql-performance
Sun Fire T2000 has 3 PCI-E and 1PCI-X slot free when shipped. Using
dual fiber channel 2G adapters you can get about 200MB x 8 = 1600MB/sec
IO bandwidth. Plus when 4G HBAs are supported that will double up. Now I
think generally that's good enough for 1TB raw data or 2-3 TB Database
size. Of course typically the database size in PostgreSQL space will be
in the 100-500GB range so a Sun Fire T2000 can be a good fit with enough
area to grow at a very reasonable price.
Of course like someone mentioned if all you have is 1 connection using
postgresql which cannot spawn helper processes/threads, this will be
limited by the single thread performance which is about 1.2Ghz compared
on Sun Fire T2000 to AMD64 (Sun Fire X4200) which pretty much has
similar IO Bandwidth, same size chassis, but the individual AMD64 cores
runs at about 2.4Ghz (I believe) and max you can get is 4 cores but you
also have to do a little trade off in terms of power consumption in lei
of faster single thread performance. So Choices are available with both
architecture. .However if you have a webserver driving a postgreSQL
backend, then UltraSPARC T1 might be a better option if you suddenly
wants to do 100s of db connections. The SunFire T2000 gives you 8 cores
with 32 threads in all running on the system.
With PostgreSQL 8.1 fix for SMP Bufferpool performance and with ZFS now
available in Solaris Express release, it would be interesting to see how
the combination of PostgreSQL 8.1 and ZFS works on Solaris since ZFS is
one of the perfect file systems for PostgreSQL where it wants all
complexities (like block allocation, fragmentation, etc) to the
underlying file systems and not re-implement its own infrastructure.
If somebody is already conducting their own tests, do let me know. As
soon as I get some free cycles, I want to run ZFS with PostgreSQL using
Solaris Express. If you have some preferred workloads do let me know.
Regards,
Jignesh
Luke Lonergan wrote:
>Juan,
>
>On 12/18/05 8:35 AM, "Juan Casero" <caseroj@comcast.net> wrote:
>
>
>
>>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 handle a
>>database that might grow to a 100 GB. Our company is green mission conscious
>>now so I was hoping I could use that to convince management to consider a Sun
>>Ultrasparc T1 or T2 system provided that if I can get the best performance
>>out of it on PostgreSQL. So will newer versions of PostgreSQL (8.1.x) be
>>able to take of advantage of the multiple cores on a T1 or T2? I cannot
>>change the database and this will be a hard sell unless I can convince them
>>that the performance advantages are too good to pass up. The company is
>>moving in the Win32 direction and so I have to provide rock solid reasons for
>>why I want to use Solaris Sparc on a T1 or T2 server for this database
>>application instead of Windows on SQL Server.
>>
>>
>
>The Niagara CPUs are heavily multi-threaded and will require a lot of
>parallelism to be exposed to them in order to be effective.
>
>Until Sun makes niagara-based machines with lots of I/O channels, there
>won't be much I/O parallelism available to match the CPU parallelism.
>
>Bizgres MPP will use the process and I/O parallelism of these big SMP
>machines and the version based on Postgres 8.1 will be out in February.
>
>- Luke
>
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 5: don't forget to increase your free space map settings
>
>
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: PostgreSQL and Ultrasparc T1
2005-12-18 16:35 PostgreSQL and Ultrasparc T1 Juan Casero <caseroj@comcast.net>
2005-12-19 07:21 ` Re: PostgreSQL and Ultrasparc T1 Luke Lonergan <llonergan@greenplum.com>
2005-12-19 14:27 ` Re: PostgreSQL and Ultrasparc T1 Jignesh K. Shah <J.K.Shah@Sun.COM>
@ 2005-12-19 17:30 ` Luke Lonergan <llonergan@greenplum.com>
2005-12-19 19:29 ` Re: PostgreSQL and Ultrasparc T1 Jignesh Shah <J.K.Shah@Sun.COM>
0 siblings, 1 reply; 22+ messages in thread
From: Luke Lonergan @ 2005-12-19 17:30 UTC (permalink / raw)
To: Jignesh Shah <J.K.Shah@Sun.COM>; +Cc: Juan Casero <caseroj@comcast.net>; pgsql-performance
Jignesh,
On 12/19/05 6:27 AM, "Jignesh K. Shah" <J.K.Shah@Sun.COM> wrote:
> Sun Fire T2000 has 3 PCI-E and 1PCI-X slot free when shipped. Using
> dual fiber channel 2G adapters you can get about 200MB x 8 = 1600MB/sec
> IO bandwidth. Plus when 4G HBAs are supported that will double up. Now I
> think generally that's good enough for 1TB raw data or 2-3 TB Database
> size. Of course typically the database size in PostgreSQL space will be
> in the 100-500GB range so a Sun Fire T2000 can be a good fit with enough
> area to grow at a very reasonable price.
The free PCI slots don't indicate the I/O speed of the machine, otherwise
I'll just go back 4 years and use a Xeon machine.
Can you educate us a bit on the T-2000, like where can we find a technical
publication that can answer the following:
Are all of the PCI-E and PCI-X independent, mastering channels? Are they
connected via a crossbar or is it using the JBus? Is the usable memory
bandwidth available to the HBAs and CPU double the 1,600MB/s, or 3,200MB/s?
> Of course like someone mentioned if all you have is 1 connection using
> postgresql which cannot spawn helper processes/threads, this will be
> limited by the single thread performance which is about 1.2Ghz compared
> on Sun Fire T2000 to AMD64 (Sun Fire X4200) which pretty much has
> similar IO Bandwidth, same size chassis, but the individual AMD64 cores
> runs at about 2.4Ghz (I believe) and max you can get is 4 cores but you
> also have to do a little trade off in terms of power consumption in lei
> of faster single thread performance. So Choices are available with both
> architecture. .However if you have a webserver driving a postgreSQL
> backend, then UltraSPARC T1 might be a better option if you suddenly
> wants to do 100s of db connections. The SunFire T2000 gives you 8 cores
> with 32 threads in all running on the system.
So - OLTP / webserver, that makes sense.
- Luke
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: PostgreSQL and Ultrasparc T1
2005-12-18 16:35 PostgreSQL and Ultrasparc T1 Juan Casero <caseroj@comcast.net>
2005-12-19 07:21 ` Re: PostgreSQL and Ultrasparc T1 Luke Lonergan <llonergan@greenplum.com>
2005-12-19 14:27 ` Re: PostgreSQL and Ultrasparc T1 Jignesh K. Shah <J.K.Shah@Sun.COM>
2005-12-19 17:30 ` Re: PostgreSQL and Ultrasparc T1 Luke Lonergan <llonergan@greenplum.com>
@ 2005-12-19 19:29 ` Jignesh Shah <J.K.Shah@Sun.COM>
2005-12-19 19:37 ` Re: PostgreSQL and Ultrasparc T1 Luke Lonergan <llonergan@greenplum.com>
0 siblings, 1 reply; 22+ messages in thread
From: Jignesh Shah @ 2005-12-19 19:29 UTC (permalink / raw)
To: Luke Lonergan <llonergan@greenplum.com>; +Cc: Juan Casero <caseroj@comcast.net>; pgsql-performance
Hi Luke,
I have gone to the max with 4 fibers on Sun Fire T2000. But I am not sure about the answers that you asked. Let me see if I can get answers for them. I am going to try to max out the IO on these systems with 8 fibers as soon as I get additional storage so stay tuned for that.
By the way you don't have to wait for my tests. Just get a trial server and try it on your own. If you don't like it return it.
https://www.sun.com/emrkt/trycoolthreads/contactme.html
Check out Jonathan's blog for more details http://blogs.sun.com/jonathan
However if you do try it with PostgreSQL, do let me know also with your experience.
Regards,
Jignesh
----- Original Message -----
From: Luke Lonergan <llonergan@greenplum.com>
Date: Monday, December 19, 2005 12:31 pm
Subject: Re: [PERFORM] PostgreSQL and Ultrasparc T1
To: Jignesh Shah <J.K.Shah@Sun.COM>
Cc: Juan Casero <caseroj@comcast.net>, pgsql-performance@postgresql.org
> Jignesh,
>
>
> On 12/19/05 6:27 AM, "Jignesh K. Shah" <J.K.Shah@Sun.COM> wrote:
>
> > Sun Fire T2000 has 3 PCI-E and 1PCI-X slot free when shipped. Using
> > dual fiber channel 2G adapters you can get about 200MB x 8 =
> 1600MB/sec> IO bandwidth. Plus when 4G HBAs are supported that will
> double up. Now I
> > think generally that's good enough for 1TB raw data or 2-3 TB
> Database> size. Of course typically the database size in PostgreSQL
> space will be
> > in the 100-500GB range so a Sun Fire T2000 can be a good fit with
> enough> area to grow at a very reasonable price.
>
> The free PCI slots don't indicate the I/O speed of the machine,
> otherwiseI'll just go back 4 years and use a Xeon machine.
>
> Can you educate us a bit on the T-2000, like where can we find a
> technicalpublication that can answer the following:
>
> Are all of the PCI-E and PCI-X independent, mastering channels?
> Are they
> connected via a crossbar or is it using the JBus? Is the usable
> memorybandwidth available to the HBAs and CPU double the 1,600MB/s,
> or 3,200MB/s?
>
> > Of course like someone mentioned if all you have is 1 connection
> using> postgresql which cannot spawn helper processes/threads, this
> will be
> > limited by the single thread performance which is about 1.2Ghz
> compared> on Sun Fire T2000 to AMD64 (Sun Fire X4200) which pretty
> much has
> > similar IO Bandwidth, same size chassis, but the individual
> AMD64 cores
> > runs at about 2.4Ghz (I believe) and max you can get is 4 cores
> but you
> > also have to do a little trade off in terms of power consumption
> in lei
> > of faster single thread performance. So Choices are available
> with both
> > architecture. .However if you have a webserver driving a postgreSQL
> > backend, then UltraSPARC T1 might be a better option if you suddenly
> > wants to do 100s of db connections. The SunFire T2000 gives you 8
> cores> with 32 threads in all running on the system.
>
> So - OLTP / webserver, that makes sense.
>
> - Luke
>
>
>
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: PostgreSQL and Ultrasparc T1
2005-12-18 16:35 PostgreSQL and Ultrasparc T1 Juan Casero <caseroj@comcast.net>
2005-12-19 07:21 ` Re: PostgreSQL and Ultrasparc T1 Luke Lonergan <llonergan@greenplum.com>
2005-12-19 14:27 ` Re: PostgreSQL and Ultrasparc T1 Jignesh K. Shah <J.K.Shah@Sun.COM>
2005-12-19 17:30 ` Re: PostgreSQL and Ultrasparc T1 Luke Lonergan <llonergan@greenplum.com>
2005-12-19 19:29 ` Re: PostgreSQL and Ultrasparc T1 Jignesh Shah <J.K.Shah@Sun.COM>
@ 2005-12-19 19:37 ` Luke Lonergan <llonergan@greenplum.com>
2005-12-19 20:21 ` Re: PostgreSQL and Ultrasparc T1 Jignesh Shah <J.K.Shah@Sun.COM>
0 siblings, 1 reply; 22+ messages in thread
From: Luke Lonergan @ 2005-12-19 19:37 UTC (permalink / raw)
To: Jignesh Shah <J.K.Shah@Sun.COM>; +Cc: Juan Casero <caseroj@comcast.net>; pgsql-performance
Jignesh,
On 12/19/05 11:29 AM, "Jignesh Shah" <J.K.Shah@Sun.COM> wrote:
> I have gone to the max with 4 fibers on Sun Fire T2000. But I am not sure
> about the answers that you asked. Let me see if I can get answers for them. I
> am going to try to max out the IO on these systems with 8 fibers as soon as I
> get additional storage so stay tuned for that.
Cool - how close did you get to 800MB/s?
> By the way you don't have to wait for my tests. Just get a trial server and
> try it on your own. If you don't like it return it.
>
> https://www.sun.com/emrkt/trycoolthreads/contactme.html
Done - I'll certainly test Postgres / Bizgres on it - you know me ;-)
> However if you do try it with PostgreSQL, do let me know also with your
> experience.
See above.
The Niagara is UltraSparc III compatible - so the GCC compiler should emit
good code for it, right?
- Luke
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: PostgreSQL and Ultrasparc T1
2005-12-18 16:35 PostgreSQL and Ultrasparc T1 Juan Casero <caseroj@comcast.net>
2005-12-19 07:21 ` Re: PostgreSQL and Ultrasparc T1 Luke Lonergan <llonergan@greenplum.com>
2005-12-19 14:27 ` Re: PostgreSQL and Ultrasparc T1 Jignesh K. Shah <J.K.Shah@Sun.COM>
2005-12-19 17:30 ` Re: PostgreSQL and Ultrasparc T1 Luke Lonergan <llonergan@greenplum.com>
2005-12-19 19:29 ` Re: PostgreSQL and Ultrasparc T1 Jignesh Shah <J.K.Shah@Sun.COM>
2005-12-19 19:37 ` Re: PostgreSQL and Ultrasparc T1 Luke Lonergan <llonergan@greenplum.com>
@ 2005-12-19 20:21 ` Jignesh Shah <J.K.Shah@Sun.COM>
2005-12-20 01:34 ` Re: PostgreSQL and Ultrasparc T1 Luke Lonergan <llonergan@greenplum.com>
2005-12-20 01:37 ` Re: PostgreSQL and Ultrasparc T1 Luke Lonergan <llonergan@greenplum.com>
0 siblings, 2 replies; 22+ messages in thread
From: Jignesh Shah @ 2005-12-19 20:21 UTC (permalink / raw)
To: Luke Lonergan <llonergan@greenplum.com>; +Cc: Juan Casero <caseroj@comcast.net>; pgsql-performance
Hi Luke,
I got about 720 MB/sec to 730 MB/sec with plain dd tests on my current storage configuration (8 LUNS on 4 fibers) which slowed me down (10K rpm 146 GB disks FC) with 4 LUNS going through a longer pass to the disks (via a controller master array to slave JBODs to provide ) .
extended device statistics
r/s w/s Mr/s Mw/s wait actv wsvc_t asvc_t %w %b device
0.8 14.0 0.0 0.0 0.0 0.3 0.0 17.8 0 4 c3t0d0
91.4 0.0 91.4 0.0 0.0 1.0 0.0 10.5 0 96 c0t40d0
96.0 0.0 96.0 0.0 0.0 1.0 0.0 10.0 0 96 c5t40d1
95.8 0.0 95.8 0.0 0.0 1.0 0.0 10.0 0 96 c0t40d1
96.8 0.0 96.8 0.0 0.0 1.0 0.0 9.9 0 96 c5t40d0
84.6 0.0 84.6 0.0 0.0 1.0 0.0 11.4 0 96 c4t46d1
85.6 0.0 85.6 0.0 0.0 1.0 0.0 11.2 0 96 c4t46d0
85.2 0.0 85.2 0.0 0.0 1.0 0.0 11.3 0 96 c2t46d1
85.4 0.0 85.4 0.0 0.0 1.0 0.0 11.3 0 96 c2t46d0
I can probably bump it up a bit with fine storage tuning (LUN) but there is no limitation on the Sun Fire T2000 to bottleneck on anything plus dd tests are not the best throughput measurement tool.
Yes UltraSPARC T1 supports the SPARC V9 architecture and can support all the SPARC binaries already generated or newly generated using gcc or Sun Studio 11 which is also free.
http://developers.sun.com/prodtech/cc/downloads/sun_studio/
Regards,
Jignesh
----- Original Message -----
From: Luke Lonergan <llonergan@greenplum.com>
Date: Monday, December 19, 2005 2:38 pm
Subject: Re: [PERFORM] PostgreSQL and Ultrasparc T1
To: Jignesh Shah <J.K.Shah@Sun.COM>
Cc: Juan Casero <caseroj@comcast.net>, pgsql-performance@postgresql.org
> Jignesh,
>
> On 12/19/05 11:29 AM, "Jignesh Shah" <J.K.Shah@Sun.COM> wrote:
>
> > I have gone to the max with 4 fibers on Sun Fire T2000. But I am
> not sure
> > about the answers that you asked. Let me see if I can get answers
> for them. I
> > am going to try to max out the IO on these systems with 8 fibers
> as soon as I
> > get additional storage so stay tuned for that.
>
> Cool - how close did you get to 800MB/s?
>
> > By the way you don't have to wait for my tests. Just get a trial
> server and
> > try it on your own. If you don't like it return it.
> >
> > https://www.sun.com/emrkt/trycoolthreads/contactme.html
>
> Done - I'll certainly test Postgres / Bizgres on it - you know me ;-)
>
> > However if you do try it with PostgreSQL, do let me know also
> with your
> > experience.
>
> See above.
>
> The Niagara is UltraSparc III compatible - so the GCC compiler
> should emit
> good code for it, right?
>
> - Luke
>
>
>
> ---------------------------(end of broadcast)-----------------------
> ----
> TIP 2: Don't 'kill -9' the postmaster
>
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: PostgreSQL and Ultrasparc T1
2005-12-18 16:35 PostgreSQL and Ultrasparc T1 Juan Casero <caseroj@comcast.net>
2005-12-19 07:21 ` Re: PostgreSQL and Ultrasparc T1 Luke Lonergan <llonergan@greenplum.com>
2005-12-19 14:27 ` Re: PostgreSQL and Ultrasparc T1 Jignesh K. Shah <J.K.Shah@Sun.COM>
2005-12-19 17:30 ` Re: PostgreSQL and Ultrasparc T1 Luke Lonergan <llonergan@greenplum.com>
2005-12-19 19:29 ` Re: PostgreSQL and Ultrasparc T1 Jignesh Shah <J.K.Shah@Sun.COM>
2005-12-19 19:37 ` Re: PostgreSQL and Ultrasparc T1 Luke Lonergan <llonergan@greenplum.com>
2005-12-19 20:21 ` Re: PostgreSQL and Ultrasparc T1 Jignesh Shah <J.K.Shah@Sun.COM>
@ 2005-12-20 01:34 ` Luke Lonergan <llonergan@greenplum.com>
1 sibling, 0 replies; 22+ messages in thread
From: Luke Lonergan @ 2005-12-20 01:34 UTC (permalink / raw)
To: Jignesh Shah <J.K.Shah@Sun.COM>; +Cc: Juan Casero <caseroj@comcast.net>; pgsql-performance
Jignesh,
On 12/19/05 12:21 PM, "Jignesh Shah" <J.K.Shah@Sun.COM> wrote:
> I got about 720 MB/sec to 730 MB/sec with plain dd tests on my current
> storage configuration (8 LUNS on 4 fibers) which slowed me down (10K rpm 146
> GB disks FC) with 4 LUNS going through a longer pass to the disks (via a
> controller master array to slave JBODs to provide ) .
>
> extended device statistics
> r/s w/s Mr/s Mw/s wait actv wsvc_t asvc_t %w %b device
> 0.8 14.0 0.0 0.0 0.0 0.3 0.0 17.8 0 4 c3t0d0
> 91.4 0.0 91.4 0.0 0.0 1.0 0.0 10.5 0 96 c0t40d0
> 96.0 0.0 96.0 0.0 0.0 1.0 0.0 10.0 0 96 c5t40d1
> 95.8 0.0 95.8 0.0 0.0 1.0 0.0 10.0 0 96 c0t40d1
Can you please explain these columns? R/s, is that millions of pages or
extents or something? How do I translate this to 730 million bytes per
second?
- Luke
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: PostgreSQL and Ultrasparc T1
2005-12-18 16:35 PostgreSQL and Ultrasparc T1 Juan Casero <caseroj@comcast.net>
2005-12-19 07:21 ` Re: PostgreSQL and Ultrasparc T1 Luke Lonergan <llonergan@greenplum.com>
2005-12-19 14:27 ` Re: PostgreSQL and Ultrasparc T1 Jignesh K. Shah <J.K.Shah@Sun.COM>
2005-12-19 17:30 ` Re: PostgreSQL and Ultrasparc T1 Luke Lonergan <llonergan@greenplum.com>
2005-12-19 19:29 ` Re: PostgreSQL and Ultrasparc T1 Jignesh Shah <J.K.Shah@Sun.COM>
2005-12-19 19:37 ` Re: PostgreSQL and Ultrasparc T1 Luke Lonergan <llonergan@greenplum.com>
2005-12-19 20:21 ` Re: PostgreSQL and Ultrasparc T1 Jignesh Shah <J.K.Shah@Sun.COM>
@ 2005-12-20 01:37 ` Luke Lonergan <llonergan@greenplum.com>
1 sibling, 0 replies; 22+ messages in thread
From: Luke Lonergan @ 2005-12-20 01:37 UTC (permalink / raw)
To: Jignesh Shah <J.K.Shah@Sun.COM>; +Cc: Juan Casero <caseroj@comcast.net>; pgsql-performance
Jignesh,
On 12/19/05 12:21 PM, "Jignesh Shah" <J.K.Shah@Sun.COM> wrote:
> extended device statistics
> r/s w/s Mr/s Mw/s wait actv wsvc_t asvc_t %w %b device
> 0.8 14.0 0.0 0.0 0.0 0.3 0.0 17.8 0 4 c3t0d0
> 91.4 0.0 91.4 0.0 0.0 1.0 0.0 10.5 0 96 c0t40d0
> 96.0 0.0 96.0 0.0 0.0 1.0 0.0 10.0 0 96 c5t40d1
> 95.8 0.0 95.8 0.0 0.0 1.0 0.0 10.0 0 96 c0t40d1
> 96.8 0.0 96.8 0.0 0.0 1.0 0.0 9.9 0 96 c5t40d0
> 84.6 0.0 84.6 0.0 0.0 1.0 0.0 11.4 0 96 c4t46d1
> 85.6 0.0 85.6 0.0 0.0 1.0 0.0 11.2 0 96 c4t46d0
> 85.2 0.0 85.2 0.0 0.0 1.0 0.0 11.3 0 96 c2t46d1
> 85.4 0.0 85.4 0.0 0.0 1.0 0.0 11.3 0 96 c2t46d0
Doh! Forget my last message, each of these is a single drive.
Wacky layout though - it looks like c0,c2,c3,c4,c5 - is that 5 controllers
there?
Also - what are the RAID options on this unit?
To get optimal performance on an 8 core unit, would we want to map 1 active
process to each of these drives? Can the CPU run all 8 threads
simultaneously?
- Luke
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: PostgreSQL and Ultrasparc T1
2005-12-18 16:35 PostgreSQL and Ultrasparc T1 Juan Casero <caseroj@comcast.net>
@ 2005-12-20 19:34 ` Jim C. Nasby <jnasby@pervasive.com>
2 siblings, 0 replies; 22+ messages in thread
From: Jim C. Nasby @ 2005-12-20 19:34 UTC (permalink / raw)
To: Juan Casero <caseroj@comcast.net>; +Cc: pgsql-performance
On Sun, Dec 18, 2005 at 11:35:15AM -0500, Juan Casero wrote:
> 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
People have seen some pretty big gains going from 7.4 to 8.1. I recently
migrated http://stats.distributed.net and the daily processing
(basically OLAP) times were cut in half.
As someone else mentioned, IO is probably going to be your biggest
consideration, unless you have a lot of queries running at once.
Probably your best bang for the buck will be from an Opteron-based
server with a good number of internal drives.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: PostgreSQL and Ultrasparc T1
@ 2005-12-19 06:25 Scott Marlowe <smarlowe@g2switchworks.com>
2005-12-20 00:32 ` Re: PostgreSQL and Ultrasparc T1 Juan Casero <caseroj@comcast.net>
0 siblings, 1 reply; 22+ messages in thread
From: Scott Marlowe @ 2005-12-19 06:25 UTC (permalink / raw)
To: Juan Casero <caseroj@comcast.net>; pgsql-performance
From: pgsql-performance-owner@postgresql.org 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 developed using PostgreSQL 7.48 and PHP on a Fedora
Core 3 intel box. I want to scale this application upwards to handle a
database that might grow to a 100 GB. Our company is green mission conscious
now so I was hoping I could use that to convince management to consider a Sun
Ultrasparc T1 or T2 system provided that if I can get the best performance
out of it on PostgreSQL.
ENDQUOTE:
Well, generally, AMD 64 bit is going to be a better value for your dollar, and run faster than most Sparc based machines.
Also, PostgreSQL is generally faster under either BSD or Linux than under Solaris on the same box. This might or might not hold as you crank up the numbers of CPUs.
PostgreSQL runs one process for connection. So, to use extra CPUs, you really need to have >1 connection running against the database.
Mostly, databases tend to be either I/O bound, until you give them a lot of I/O, then they'll be CPU bound.
After that lots of memory, THEN more CPUs. Two CPUs is always useful, as one can be servicing the OS and another the database. But unless you're gonna have lots of users hooked up, more than 2 to 4 CPUs is usually a waste.
So, I'd recommend a dual core or dual dual core (i.e. 4 cores) AMD64 system with 2 or more gigs ram, and at least a pair of fast drives in a mirror with a hardare RAID controller with battery backed cache. If you'll be trundling through all 100 gigs of your data set regularly, then get all the memory you can put in a machine at a reasonable cost before buying lots of CPUs.
But without knowing what you're gonna be doing we can't really make solid recommendations...
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: PostgreSQL and Ultrasparc T1
2005-12-19 06:25 Re: PostgreSQL and Ultrasparc T1 Scott Marlowe <smarlowe@g2switchworks.com>
@ 2005-12-20 00:32 ` Juan Casero <caseroj@comcast.net>
2005-12-20 04:19 ` Re: PostgreSQL and Ultrasparc T1 Jignesh K. Shah <J.K.Shah@Sun.COM>
0 siblings, 1 reply; 22+ messages in thread
From: Juan Casero @ 2005-12-20 00:32 UTC (permalink / raw)
To: pgsql-performance
Ok. That is what I wanted to know. Right now this database is a PostgreSQL
7.4.8 system. I am using it in a sort of DSS role. I have weekly summaries
of the sales for our division going back three years. I have a PHP based
webapp that I wrote to give the managers access to this data. The webapp
lets them make selections for reports and then it submits a parameterized
query to the database for execution. The returned data rows are displayed
and formatted in their web browser. My largest sales table is about 13
million rows along with all the indexes it takes up about 20 gigabytes. I
need to scale this application up to nearly 100 gigabytes to handle daily
sales summaries. Once we start looking at daily sales figures our database
size could grow ten to twenty times. I use postgresql because it gives me
the kind of enterprise database features I need to program the complex logic
for the queries. I also need the transaction isolation facilities it
provides so I can optimize the queries in plpgsql without worrying about
multiple users temp tables colliding with each other. Additionally, I hope
to rewrite the front end application in JSP so maybe I could use the
multithreaded features of the Java to exploit a multicore multi-cpu system.
There are almost no writes to the database tables. The bulk of the
application is just executing parameterized queries and returning huge
amounts of data. I know bizgres is supposed to be better at this but I want
to stay away from anything that is beta. I cannot afford for this thing to
go wrong. My reasoning for looking at the T1000/2000 was simply the large
number of cores. I know postgresql uses a super server that forks copies of
itself to handle incoming requests on port 5432. But I figured the number of
cores on the T1000/2000 processors would be utilized by the forked copies of
the postgresql server. From the comments I have seen so far it does not look
like this is the case. We had originally sized up a dual processor dual core
AMD opteron system from HP for this but I thought I could get more bang for
the buck on a T1000/2000. It now seems I may have been wrong. I am stronger
in Linux than Solaris so I am not upset I am just trying to find the best
hardware for the anticipated needs of this application.
Thanks,
Juan
On Monday 19 December 2005 01:25, Scott Marlowe wrote:
> From: pgsql-performance-owner@postgresql.org 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 developed using PostgreSQL 7.48 and PHP
> on a Fedora Core 3 intel box. I want to scale this application upwards to
> handle a database that might grow to a 100 GB. Our company is green
> mission conscious now so I was hoping I could use that to convince
> management to consider a Sun Ultrasparc T1 or T2 system provided that if I
> can get the best performance out of it on PostgreSQL.
>
> ENDQUOTE:
>
> Well, generally, AMD 64 bit is going to be a better value for your dollar,
> and run faster than most Sparc based machines.
>
> Also, PostgreSQL is generally faster under either BSD or Linux than under
> Solaris on the same box. This might or might not hold as you crank up the
> numbers of CPUs.
>
> PostgreSQL runs one process for connection. So, to use extra CPUs, you
> really need to have >1 connection running against the database.
>
> Mostly, databases tend to be either I/O bound, until you give them a lot of
> I/O, then they'll be CPU bound.
>
> After that lots of memory, THEN more CPUs. Two CPUs is always useful, as
> one can be servicing the OS and another the database. But unless you're
> gonna have lots of users hooked up, more than 2 to 4 CPUs is usually a
> waste.
>
> So, I'd recommend a dual core or dual dual core (i.e. 4 cores) AMD64 system
> with 2 or more gigs ram, and at least a pair of fast drives in a mirror
> with a hardare RAID controller with battery backed cache. If you'll be
> trundling through all 100 gigs of your data set regularly, then get all the
> memory you can put in a machine at a reasonable cost before buying lots of
> CPUs.
>
> But without knowing what you're gonna be doing we can't really make solid
> recommendations...
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: PostgreSQL and Ultrasparc T1
2005-12-19 06:25 Re: PostgreSQL and Ultrasparc T1 Scott Marlowe <smarlowe@g2switchworks.com>
2005-12-20 00:32 ` Re: PostgreSQL and Ultrasparc T1 Juan Casero <caseroj@comcast.net>
@ 2005-12-20 04:19 ` Jignesh K. Shah <J.K.Shah@Sun.COM>
2005-12-20 15:01 ` Re: PostgreSQL and Ultrasparc T1 Alan Stange <stange@rentec.com>
2005-12-20 16:50 ` Re: PostgreSQL and Ultrasparc T1 Richard_D_Levine@raytheon.com
0 siblings, 2 replies; 22+ messages in thread
From: Jignesh K. Shah @ 2005-12-20 04:19 UTC (permalink / raw)
To: Juan Casero <caseroj@comcast.net>; +Cc: pgsql-performance
I guess it depends on what you term as your metric for measurement.
If it is just one query execution time .. It may not be the best on
UltraSPARC T1.
But if you have more than 8 complex queries running simultaneously,
UltraSPARC T1 can do well compared comparatively provided the
application can scale also along with it.
The best way to approach is to figure out your peak workload, find an
accurate way to measure the "true" metric and then design a benchmark
for it and run it on both servers.
Regards,
Jignesh
Juan Casero wrote:
>Ok. That is what I wanted to know. Right now this database is a PostgreSQL
>7.4.8 system. I am using it in a sort of DSS role. I have weekly summaries
>of the sales for our division going back three years. I have a PHP based
>webapp that I wrote to give the managers access to this data. The webapp
>lets them make selections for reports and then it submits a parameterized
>query to the database for execution. The returned data rows are displayed
>and formatted in their web browser. My largest sales table is about 13
>million rows along with all the indexes it takes up about 20 gigabytes. I
>need to scale this application up to nearly 100 gigabytes to handle daily
>sales summaries. Once we start looking at daily sales figures our database
>size could grow ten to twenty times. I use postgresql because it gives me
>the kind of enterprise database features I need to program the complex logic
>for the queries. I also need the transaction isolation facilities it
>provides so I can optimize the queries in plpgsql without worrying about
>multiple users temp tables colliding with each other. Additionally, I hope
>to rewrite the front end application in JSP so maybe I could use the
>multithreaded features of the Java to exploit a multicore multi-cpu system.
>There are almost no writes to the database tables. The bulk of the
>application is just executing parameterized queries and returning huge
>amounts of data. I know bizgres is supposed to be better at this but I want
>to stay away from anything that is beta. I cannot afford for this thing to
>go wrong. My reasoning for looking at the T1000/2000 was simply the large
>number of cores. I know postgresql uses a super server that forks copies of
>itself to handle incoming requests on port 5432. But I figured the number of
>cores on the T1000/2000 processors would be utilized by the forked copies of
>the postgresql server. From the comments I have seen so far it does not look
>like this is the case. We had originally sized up a dual processor dual core
>AMD opteron system from HP for this but I thought I could get more bang for
>the buck on a T1000/2000. It now seems I may have been wrong. I am stronger
>in Linux than Solaris so I am not upset I am just trying to find the best
>hardware for the anticipated needs of this application.
>
>Thanks,
>Juan
>
>On Monday 19 December 2005 01:25, Scott Marlowe wrote:
>
>
>>From: pgsql-performance-owner@postgresql.org 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 developed using PostgreSQL 7.48 and PHP
>>on a Fedora Core 3 intel box. I want to scale this application upwards to
>>handle a database that might grow to a 100 GB. Our company is green
>>mission conscious now so I was hoping I could use that to convince
>>management to consider a Sun Ultrasparc T1 or T2 system provided that if I
>>can get the best performance out of it on PostgreSQL.
>>
>>ENDQUOTE:
>>
>>Well, generally, AMD 64 bit is going to be a better value for your dollar,
>>and run faster than most Sparc based machines.
>>
>>Also, PostgreSQL is generally faster under either BSD or Linux than under
>>Solaris on the same box. This might or might not hold as you crank up the
>>numbers of CPUs.
>>
>>PostgreSQL runs one process for connection. So, to use extra CPUs, you
>>really need to have >1 connection running against the database.
>>
>>Mostly, databases tend to be either I/O bound, until you give them a lot of
>>I/O, then they'll be CPU bound.
>>
>>After that lots of memory, THEN more CPUs. Two CPUs is always useful, as
>>one can be servicing the OS and another the database. But unless you're
>>gonna have lots of users hooked up, more than 2 to 4 CPUs is usually a
>>waste.
>>
>>So, I'd recommend a dual core or dual dual core (i.e. 4 cores) AMD64 system
>>with 2 or more gigs ram, and at least a pair of fast drives in a mirror
>>with a hardare RAID controller with battery backed cache. If you'll be
>>trundling through all 100 gigs of your data set regularly, then get all the
>>memory you can put in a machine at a reasonable cost before buying lots of
>>CPUs.
>>
>>But without knowing what you're gonna be doing we can't really make solid
>>recommendations...
>>
>>
>
>---------------------------(end of broadcast)---------------------------
>TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org
>
>
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: PostgreSQL and Ultrasparc T1
2005-12-19 06:25 Re: PostgreSQL and Ultrasparc T1 Scott Marlowe <smarlowe@g2switchworks.com>
2005-12-20 00:32 ` Re: PostgreSQL and Ultrasparc T1 Juan Casero <caseroj@comcast.net>
2005-12-20 04:19 ` Re: PostgreSQL and Ultrasparc T1 Jignesh K. Shah <J.K.Shah@Sun.COM>
@ 2005-12-20 15:01 ` Alan Stange <stange@rentec.com>
2005-12-20 15:08 ` Re: PostgreSQL and Ultrasparc T1 David Lang <dlang@invendra.net>
1 sibling, 1 reply; 22+ messages in thread
From: Alan Stange @ 2005-12-20 15:01 UTC (permalink / raw)
To: Jignesh K. Shah <J.K.Shah@Sun.COM>; +Cc: Juan Casero <caseroj@comcast.net>; pgsql-performance
Jignesh K. Shah wrote:
> I guess it depends on what you term as your metric for measurement.
> If it is just one query execution time .. It may not be the best on
> UltraSPARC T1.
> But if you have more than 8 complex queries running simultaneously,
> UltraSPARC T1 can do well compared comparatively provided the
> application can scale also along with it.
I just want to clarify one issue here. It's my understanding that the
8-core, 4 hardware thread (known as strands) system is seen as a 32 cpu
system by Solaris.
So, one could have up to 32 postgresql processes running in parallel on
the current systems (assuming the application can scale).
-- Alan
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: PostgreSQL and Ultrasparc T1
2005-12-19 06:25 Re: PostgreSQL and Ultrasparc T1 Scott Marlowe <smarlowe@g2switchworks.com>
2005-12-20 00:32 ` Re: PostgreSQL and Ultrasparc T1 Juan Casero <caseroj@comcast.net>
2005-12-20 04:19 ` Re: PostgreSQL and Ultrasparc T1 Jignesh K. Shah <J.K.Shah@Sun.COM>
2005-12-20 15:01 ` Re: PostgreSQL and Ultrasparc T1 Alan Stange <stange@rentec.com>
@ 2005-12-20 15:08 ` David Lang <dlang@invendra.net>
2005-12-20 15:14 ` Re: PostgreSQL and Ultrasparc T1 Alan Stange <stange@rentec.com>
2005-12-20 15:22 ` Re: PostgreSQL and Ultrasparc T1 David Lang <dlang@invendra.net>
0 siblings, 2 replies; 22+ messages in thread
From: David Lang @ 2005-12-20 15:08 UTC (permalink / raw)
To: Alan Stange <stange@rentec.com>; +Cc: Jignesh K. Shah <J.K.Shah@Sun.COM>; Juan Casero <caseroj@comcast.net>; pgsql-performance
On Tue, 20 Dec 2005, Alan Stange wrote:
> Jignesh K. Shah wrote:
>> I guess it depends on what you term as your metric for measurement.
>> If it is just one query execution time .. It may not be the best on
>> UltraSPARC T1.
>> But if you have more than 8 complex queries running simultaneously,
>> UltraSPARC T1 can do well compared comparatively provided the application
>> can scale also along with it.
>
> I just want to clarify one issue here. It's my understanding that the
> 8-core, 4 hardware thread (known as strands) system is seen as a 32 cpu
> system by Solaris.
> So, one could have up to 32 postgresql processes running in parallel on the
> current systems (assuming the application can scale).
note that like hyperthreading, the strands aren't full processors, their
efficiancy depends on how much other threads shareing the core stall
waiting for external things.
David Lang
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: PostgreSQL and Ultrasparc T1
2005-12-19 06:25 Re: PostgreSQL and Ultrasparc T1 Scott Marlowe <smarlowe@g2switchworks.com>
2005-12-20 00:32 ` Re: PostgreSQL and Ultrasparc T1 Juan Casero <caseroj@comcast.net>
2005-12-20 04:19 ` Re: PostgreSQL and Ultrasparc T1 Jignesh K. Shah <J.K.Shah@Sun.COM>
2005-12-20 15:01 ` Re: PostgreSQL and Ultrasparc T1 Alan Stange <stange@rentec.com>
2005-12-20 15:08 ` Re: PostgreSQL and Ultrasparc T1 David Lang <dlang@invendra.net>
@ 2005-12-20 15:14 ` Alan Stange <stange@rentec.com>
1 sibling, 0 replies; 22+ messages in thread
From: Alan Stange @ 2005-12-20 15:14 UTC (permalink / raw)
To: David Lang <dlang@invendra.net>; +Cc: Jignesh K. Shah <J.K.Shah@Sun.COM>; Juan Casero <caseroj@comcast.net>; pgsql-performance
David Lang wrote:
> On Tue, 20 Dec 2005, Alan Stange wrote:
>
>> Jignesh K. Shah wrote:
>>> I guess it depends on what you term as your metric for measurement.
>>> If it is just one query execution time .. It may not be the best on
>>> UltraSPARC T1.
>>> But if you have more than 8 complex queries running simultaneously,
>>> UltraSPARC T1 can do well compared comparatively provided the
>>> application can scale also along with it.
>>
>> I just want to clarify one issue here. It's my understanding that
>> the 8-core, 4 hardware thread (known as strands) system is seen as a
>> 32 cpu system by Solaris. So, one could have up to 32 postgresql
>> processes running in parallel on the current systems (assuming the
>> application can scale).
>
> note that like hyperthreading, the strands aren't full processors,
> their efficiancy depends on how much other threads shareing the core
> stall waiting for external things.
Exactly.
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: PostgreSQL and Ultrasparc T1
2005-12-19 06:25 Re: PostgreSQL and Ultrasparc T1 Scott Marlowe <smarlowe@g2switchworks.com>
2005-12-20 00:32 ` Re: PostgreSQL and Ultrasparc T1 Juan Casero <caseroj@comcast.net>
2005-12-20 04:19 ` Re: PostgreSQL and Ultrasparc T1 Jignesh K. Shah <J.K.Shah@Sun.COM>
2005-12-20 15:01 ` Re: PostgreSQL and Ultrasparc T1 Alan Stange <stange@rentec.com>
2005-12-20 15:08 ` Re: PostgreSQL and Ultrasparc T1 David Lang <dlang@invendra.net>
@ 2005-12-20 15:22 ` David Lang <dlang@invendra.net>
1 sibling, 0 replies; 22+ messages in thread
From: David Lang @ 2005-12-20 15:22 UTC (permalink / raw)
To: Alan Stange <stange@rentec.com>; +Cc: Jignesh K. Shah <J.K.Shah@Sun.COM>; Juan Casero <caseroj@comcast.net>; pgsql-performance
On Tue, 20 Dec 2005, Alan Stange wrote:
> David Lang wrote:
>> On Tue, 20 Dec 2005, Alan Stange wrote:
>>
>>> Jignesh K. Shah wrote:
>>>> I guess it depends on what you term as your metric for measurement.
>>>> If it is just one query execution time .. It may not be the best on
>>>> UltraSPARC T1.
>>>> But if you have more than 8 complex queries running simultaneously,
>>>> UltraSPARC T1 can do well compared comparatively provided the application
>>>> can scale also along with it.
>>>
>>> I just want to clarify one issue here. It's my understanding that the
>>> 8-core, 4 hardware thread (known as strands) system is seen as a 32 cpu
>>> system by Solaris. So, one could have up to 32 postgresql processes
>>> running in parallel on the current systems (assuming the application can
>>> scale).
>>
>> note that like hyperthreading, the strands aren't full processors, their
>> efficiancy depends on how much other threads shareing the core stall
>> waiting for external things.
> Exactly. Until we have a machine in hand (and substantial technical
> documentation) we won't know all the limitations.
by the way, when you do get your hands on it I would be interested to hear
how Linux compares to Solaris on the same hardware.
given how new the hardware is it's also likly that linux won't identify
the hardware properly (either seeing it as 32 true processors or just as 8
without being able to use the strands), so the intitial tests may not
reflect the Linux performance in a release or two.
David Lang
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: PostgreSQL and Ultrasparc T1
2005-12-19 06:25 Re: PostgreSQL and Ultrasparc T1 Scott Marlowe <smarlowe@g2switchworks.com>
2005-12-20 00:32 ` Re: PostgreSQL and Ultrasparc T1 Juan Casero <caseroj@comcast.net>
2005-12-20 04:19 ` Re: PostgreSQL and Ultrasparc T1 Jignesh K. Shah <J.K.Shah@Sun.COM>
@ 2005-12-20 16:50 ` Richard_D_Levine@raytheon.com
2005-12-20 17:20 ` Re: PostgreSQL and Ultrasparc T1 Jignesh K. Shah <J.K.Shah@Sun.COM>
1 sibling, 1 reply; 22+ messages in thread
From: Richard_D_Levine@raytheon.com @ 2005-12-20 16:50 UTC (permalink / raw)
To: Jignesh K. Shah <J.K.Shah@Sun.COM>; +Cc: Juan Casero <caseroj@comcast.net>; pgsql-performance; pgsql-performance-owner@postgresql.org
Jignesh,
Juan says the following below:
"I figured the number of cores on the T1000/2000 processors would be
utilized by the forked copies of the postgresql server. From the comments
I have seen so far it does not look like this is the case."
I think this needs to be refuted. Doesn't Solaris switch processes as well
as threads (LWPs, whatever) equally well amongst cores? I realize the
process context switch is more expensive than the thread switch, but
Solaris will utilize all cores as processes or threads become ready to run,
correct?
BTW, it's great to see folks with your email address on the list. I feel
it points to a brighter future for all involved.
Thanks,
Rick
"Jignesh K. Shah"
<J.K.Shah@Sun.COM
> To
Sent by: Juan Casero <caseroj@comcast.net>
pgsql-performance cc
-owner@postgresql pgsql-performance@postgresql.org
.org Subject
Re: [PERFORM] PostgreSQL and
Ultrasparc T1
12/19/2005 11:19
PM
I guess it depends on what you term as your metric for measurement.
If it is just one query execution time .. It may not be the best on
UltraSPARC T1.
But if you have more than 8 complex queries running simultaneously,
UltraSPARC T1 can do well compared comparatively provided the
application can scale also along with it.
The best way to approach is to figure out your peak workload, find an
accurate way to measure the "true" metric and then design a benchmark
for it and run it on both servers.
Regards,
Jignesh
Juan Casero wrote:
>Ok. That is what I wanted to know. Right now this database is a
PostgreSQL
>7.4.8 system. I am using it in a sort of DSS role. I have weekly
summaries
>of the sales for our division going back three years. I have a PHP based
>webapp that I wrote to give the managers access to this data. The webapp
>lets them make selections for reports and then it submits a parameterized
>query to the database for execution. The returned data rows are displayed
>and formatted in their web browser. My largest sales table is about 13
>million rows along with all the indexes it takes up about 20 gigabytes. I
>need to scale this application up to nearly 100 gigabytes to handle daily
>sales summaries. Once we start looking at daily sales figures our
database
>size could grow ten to twenty times. I use postgresql because it gives me
>the kind of enterprise database features I need to program the complex
logic
>for the queries. I also need the transaction isolation facilities it
>provides so I can optimize the queries in plpgsql without worrying about
>multiple users temp tables colliding with each other. Additionally, I
hope
>to rewrite the front end application in JSP so maybe I could use the
>multithreaded features of the Java to exploit a multicore multi-cpu
system.
>There are almost no writes to the database tables. The bulk of the
>application is just executing parameterized queries and returning huge
>amounts of data. I know bizgres is supposed to be better at this but I
want
>to stay away from anything that is beta. I cannot afford for this thing
to
>go wrong. My reasoning for looking at the T1000/2000 was simply the large
>number of cores. I know postgresql uses a super server that forks copies
of
>itself to handle incoming requests on port 5432. But I figured the number
of
>cores on the T1000/2000 processors would be utilized by the forked copies
of
>the postgresql server. From the comments I have seen so far it does not
look
>like this is the case. We had originally sized up a dual processor dual
core
>AMD opteron system from HP for this but I thought I could get more bang
for
>the buck on a T1000/2000. It now seems I may have been wrong. I am
stronger
>in Linux than Solaris so I am not upset I am just trying to find the best
>hardware for the anticipated needs of this application.
>
>Thanks,
>Juan
>
>On Monday 19 December 2005 01:25, Scott Marlowe wrote:
>
>
>>From: pgsql-performance-owner@postgresql.org 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 developed using PostgreSQL 7.48 and
PHP
>>on a Fedora Core 3 intel box. I want to scale this application upwards
to
>>handle a database that might grow to a 100 GB. Our company is green
>>mission conscious now so I was hoping I could use that to convince
>>management to consider a Sun Ultrasparc T1 or T2 system provided that if
I
>>can get the best performance out of it on PostgreSQL.
>>
>>ENDQUOTE:
>>
>>Well, generally, AMD 64 bit is going to be a better value for your
dollar,
>>and run faster than most Sparc based machines.
>>
>>Also, PostgreSQL is generally faster under either BSD or Linux than under
>>Solaris on the same box. This might or might not hold as you crank up
the
>>numbers of CPUs.
>>
>>PostgreSQL runs one process for connection. So, to use extra CPUs, you
>>really need to have >1 connection running against the database.
>>
>>Mostly, databases tend to be either I/O bound, until you give them a lot
of
>>I/O, then they'll be CPU bound.
>>
>>After that lots of memory, THEN more CPUs. Two CPUs is always useful, as
>>one can be servicing the OS and another the database. But unless you're
>>gonna have lots of users hooked up, more than 2 to 4 CPUs is usually a
>>waste.
>>
>>So, I'd recommend a dual core or dual dual core (i.e. 4 cores) AMD64
system
>>with 2 or more gigs ram, and at least a pair of fast drives in a mirror
>>with a hardare RAID controller with battery backed cache. If you'll be
>>trundling through all 100 gigs of your data set regularly, then get all
the
>>memory you can put in a machine at a reasonable cost before buying lots
of
>>CPUs.
>>
>>But without knowing what you're gonna be doing we can't really make solid
>>recommendations...
>>
>>
>
>---------------------------(end of broadcast)---------------------------
>TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org
>
>
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: PostgreSQL and Ultrasparc T1
2005-12-19 06:25 Re: PostgreSQL and Ultrasparc T1 Scott Marlowe <smarlowe@g2switchworks.com>
2005-12-20 00:32 ` Re: PostgreSQL and Ultrasparc T1 Juan Casero <caseroj@comcast.net>
2005-12-20 04:19 ` Re: PostgreSQL and Ultrasparc T1 Jignesh K. Shah <J.K.Shah@Sun.COM>
2005-12-20 16:50 ` Re: PostgreSQL and Ultrasparc T1 Richard_D_Levine@raytheon.com
@ 2005-12-20 17:20 ` Jignesh K. Shah <J.K.Shah@Sun.COM>
2005-12-20 19:22 ` Re: PostgreSQL and Ultrasparc T1 Jim C. Nasby <jnasby@pervasive.com>
0 siblings, 1 reply; 22+ messages in thread
From: Jignesh K. Shah @ 2005-12-20 17:20 UTC (permalink / raw)
To: Richard_D_Levine@raytheon.com; +Cc: Juan Casero <caseroj@comcast.net>; pgsql-performance; pgsql-performance-owner@postgresql.org
But yes All LWPs (processes and threads) are switched across virtual
CPUS . There is intelligence built in Solaris to understand which
strands are executing on which cores and it will balance out the cores
too so if there are only 8 threads running they will essentially run on
separate cores rather than 2 cores with 8 threads.
The biggest limitation is application scaling. pgbench shows that with
more processes trying to bottleneck on same files will probably not
perform better unless you tune your storage/file system. Those are the
issues which we typically try to solve with community partners (vendors,
open source) since that gives the biggest benefits.
Best example to verify in such multi-processes environment, do you see
greater than 60% avg CPU utilization in your dual/quad config
Xeons/Itaniums, then Sun Fire T2000 will help you a lot. However if you
are stuck below 50% (for dual) or 25% (for quad) which means you are
pretty much stuck at 1 CPU performance and/or probably have more IO
related contention then it won't help you with these systems.
I hope you get the idea on when a workload will perform better on Sun
Fire T2000 without burning hands.
I will try to test some more with PostgreSQL on these systems to kind of
highlight what can work or what will not work.
Is pgbench the workload that you prefer? (It already has issues with
pg_xlog so my guess is it probably won't scale much)
If you have other workload informations let me know.
Thanks.
Regards,
Jignesh
Richard_D_Levine@raytheon.com wrote:
>Jignesh,
>
>Juan says the following below:
>
>"I figured the number of cores on the T1000/2000 processors would be
>utilized by the forked copies of the postgresql server. From the comments
>I have seen so far it does not look like this is the case."
>
>I think this needs to be refuted. Doesn't Solaris switch processes as well
>as threads (LWPs, whatever) equally well amongst cores? I realize the
>process context switch is more expensive than the thread switch, but
>Solaris will utilize all cores as processes or threads become ready to run,
>correct?
>
>BTW, it's great to see folks with your email address on the list. I feel
>it points to a brighter future for all involved.
>
>Thanks,
>
>Rick
>
>
>
> "Jignesh K. Shah"
> <J.K.Shah@Sun.COM
> > To
> Sent by: Juan Casero <caseroj@comcast.net>
> pgsql-performance cc
> -owner@postgresql pgsql-performance@postgresql.org
> .org Subject
> Re: [PERFORM] PostgreSQL and
> Ultrasparc T1
> 12/19/2005 11:19
> PM
>
>
>
>
>
>
>
>
>I guess it depends on what you term as your metric for measurement.
>If it is just one query execution time .. It may not be the best on
>UltraSPARC T1.
>But if you have more than 8 complex queries running simultaneously,
>UltraSPARC T1 can do well compared comparatively provided the
>application can scale also along with it.
>
>The best way to approach is to figure out your peak workload, find an
>accurate way to measure the "true" metric and then design a benchmark
>for it and run it on both servers.
>
>Regards,
>Jignesh
>
>
>Juan Casero wrote:
>
>
>
>>Ok. That is what I wanted to know. Right now this database is a
>>
>>
>PostgreSQL
>
>
>>7.4.8 system. I am using it in a sort of DSS role. I have weekly
>>
>>
>summaries
>
>
>>of the sales for our division going back three years. I have a PHP based
>>webapp that I wrote to give the managers access to this data. The webapp
>>lets them make selections for reports and then it submits a parameterized
>>query to the database for execution. The returned data rows are displayed
>>
>>
>
>
>
>>and formatted in their web browser. My largest sales table is about 13
>>million rows along with all the indexes it takes up about 20 gigabytes. I
>>
>>
>
>
>
>>need to scale this application up to nearly 100 gigabytes to handle daily
>>sales summaries. Once we start looking at daily sales figures our
>>
>>
>database
>
>
>>size could grow ten to twenty times. I use postgresql because it gives me
>>
>>
>
>
>
>>the kind of enterprise database features I need to program the complex
>>
>>
>logic
>
>
>>for the queries. I also need the transaction isolation facilities it
>>provides so I can optimize the queries in plpgsql without worrying about
>>multiple users temp tables colliding with each other. Additionally, I
>>
>>
>hope
>
>
>>to rewrite the front end application in JSP so maybe I could use the
>>multithreaded features of the Java to exploit a multicore multi-cpu
>>
>>
>system.
>
>
>>There are almost no writes to the database tables. The bulk of the
>>application is just executing parameterized queries and returning huge
>>amounts of data. I know bizgres is supposed to be better at this but I
>>
>>
>want
>
>
>>to stay away from anything that is beta. I cannot afford for this thing
>>
>>
>to
>
>
>>go wrong. My reasoning for looking at the T1000/2000 was simply the large
>>
>>
>
>
>
>>number of cores. I know postgresql uses a super server that forks copies
>>
>>
>of
>
>
>>itself to handle incoming requests on port 5432. But I figured the number
>>
>>
>of
>
>
>>cores on the T1000/2000 processors would be utilized by the forked copies
>>
>>
>of
>
>
>>the postgresql server. From the comments I have seen so far it does not
>>
>>
>look
>
>
>>like this is the case. We had originally sized up a dual processor dual
>>
>>
>core
>
>
>>AMD opteron system from HP for this but I thought I could get more bang
>>
>>
>for
>
>
>>the buck on a T1000/2000. It now seems I may have been wrong. I am
>>
>>
>stronger
>
>
>>in Linux than Solaris so I am not upset I am just trying to find the best
>>hardware for the anticipated needs of this application.
>>
>>Thanks,
>>Juan
>>
>>On Monday 19 December 2005 01:25, Scott Marlowe wrote:
>>
>>
>>
>>
>>>From: pgsql-performance-owner@postgresql.org 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 developed using PostgreSQL 7.48 and
>>>
>>>
>PHP
>
>
>>>on a Fedora Core 3 intel box. I want to scale this application upwards
>>>
>>>
>to
>
>
>>>handle a database that might grow to a 100 GB. Our company is green
>>>mission conscious now so I was hoping I could use that to convince
>>>management to consider a Sun Ultrasparc T1 or T2 system provided that if
>>>
>>>
>I
>
>
>>>can get the best performance out of it on PostgreSQL.
>>>
>>>ENDQUOTE:
>>>
>>>Well, generally, AMD 64 bit is going to be a better value for your
>>>
>>>
>dollar,
>
>
>>>and run faster than most Sparc based machines.
>>>
>>>Also, PostgreSQL is generally faster under either BSD or Linux than under
>>>Solaris on the same box. This might or might not hold as you crank up
>>>
>>>
>the
>
>
>>>numbers of CPUs.
>>>
>>>PostgreSQL runs one process for connection. So, to use extra CPUs, you
>>>really need to have >1 connection running against the database.
>>>
>>>Mostly, databases tend to be either I/O bound, until you give them a lot
>>>
>>>
>of
>
>
>>>I/O, then they'll be CPU bound.
>>>
>>>After that lots of memory, THEN more CPUs. Two CPUs is always useful, as
>>>one can be servicing the OS and another the database. But unless you're
>>>gonna have lots of users hooked up, more than 2 to 4 CPUs is usually a
>>>waste.
>>>
>>>So, I'd recommend a dual core or dual dual core (i.e. 4 cores) AMD64
>>>
>>>
>system
>
>
>>>with 2 or more gigs ram, and at least a pair of fast drives in a mirror
>>>with a hardare RAID controller with battery backed cache. If you'll be
>>>trundling through all 100 gigs of your data set regularly, then get all
>>>
>>>
>the
>
>
>>>memory you can put in a machine at a reasonable cost before buying lots
>>>
>>>
>of
>
>
>>>CPUs.
>>>
>>>But without knowing what you're gonna be doing we can't really make solid
>>>recommendations...
>>>
>>>
>>>
>>>
>>---------------------------(end of broadcast)---------------------------
>>TIP 4: Have you searched our list archives?
>>
>> http://archives.postgresql.org
>>
>>
>>
>>
>
>---------------------------(end of broadcast)---------------------------
>TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>
>
>
>
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: PostgreSQL and Ultrasparc T1
2005-12-19 06:25 Re: PostgreSQL and Ultrasparc T1 Scott Marlowe <smarlowe@g2switchworks.com>
2005-12-20 00:32 ` Re: PostgreSQL and Ultrasparc T1 Juan Casero <caseroj@comcast.net>
2005-12-20 04:19 ` Re: PostgreSQL and Ultrasparc T1 Jignesh K. Shah <J.K.Shah@Sun.COM>
2005-12-20 16:50 ` Re: PostgreSQL and Ultrasparc T1 Richard_D_Levine@raytheon.com
2005-12-20 17:20 ` Re: PostgreSQL and Ultrasparc T1 Jignesh K. Shah <J.K.Shah@Sun.COM>
@ 2005-12-20 19:22 ` Jim C. Nasby <jnasby@pervasive.com>
0 siblings, 0 replies; 22+ messages in thread
From: Jim C. Nasby @ 2005-12-20 19:22 UTC (permalink / raw)
To: Jignesh K. Shah <J.K.Shah@Sun.COM>; +Cc: Richard_D_Levine@raytheon.com, Juan Casero <caseroj@comcast.net>; pgsql-performance; pgsql-performance-owner@postgresql.org
On Tue, Dec 20, 2005 at 12:20:55PM -0500, Jignesh K. Shah wrote:
> Is pgbench the workload that you prefer? (It already has issues with
> pg_xlog so my guess is it probably won't scale much)
> If you have other workload informations let me know.
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: PostgreSQL and Ultrasparc T1
@ 2005-12-19 15:21 Anjan Dave <adave@vantage.com>
0 siblings, 0 replies; 22+ messages in thread
From: Anjan Dave @ 2005-12-19 15:21 UTC (permalink / raw)
To: Jignesh K. Shah <J.K.Shah@Sun.COM>; Luke Lonergan <llonergan@greenplum.com>; +Cc: Juan Casero <caseroj@comcast.net>; pgsql-performance
8 HBAs at 200MB/sec would require a pretty significant Storage Processor
backend unless cost is not a factor. Once you achieve that, there's a
question of sharing/balancing I/O requirements of various other
applications/databases on that same shared backend storage...
Anjan
-----Original Message-----
From: Jignesh K. Shah [mailto:J.K.Shah@Sun.COM]
Sent: Monday, December 19, 2005 9:27 AM
To: Luke Lonergan
Cc: Juan Casero; pgsql-performance@postgresql.org
Subject: Re: [PERFORM] PostgreSQL and Ultrasparc T1
Sun Fire T2000 has 3 PCI-E and 1PCI-X slot free when shipped. Using
dual fiber channel 2G adapters you can get about 200MB x 8 = 1600MB/sec
IO bandwidth. Plus when 4G HBAs are supported that will double up. Now I
think generally that's good enough for 1TB raw data or 2-3 TB Database
size. Of course typically the database size in PostgreSQL space will be
in the 100-500GB range so a Sun Fire T2000 can be a good fit with enough
area to grow at a very reasonable price.
Of course like someone mentioned if all you have is 1 connection using
postgresql which cannot spawn helper processes/threads, this will be
limited by the single thread performance which is about 1.2Ghz compared
on Sun Fire T2000 to AMD64 (Sun Fire X4200) which pretty much has
similar IO Bandwidth, same size chassis, but the individual AMD64 cores
runs at about 2.4Ghz (I believe) and max you can get is 4 cores but you
also have to do a little trade off in terms of power consumption in lei
of faster single thread performance. So Choices are available with both
architecture. .However if you have a webserver driving a postgreSQL
backend, then UltraSPARC T1 might be a better option if you suddenly
wants to do 100s of db connections. The SunFire T2000 gives you 8 cores
with 32 threads in all running on the system.
With PostgreSQL 8.1 fix for SMP Bufferpool performance and with ZFS now
available in Solaris Express release, it would be interesting to see how
the combination of PostgreSQL 8.1 and ZFS works on Solaris since ZFS is
one of the perfect file systems for PostgreSQL where it wants all
complexities (like block allocation, fragmentation, etc) to the
underlying file systems and not re-implement its own infrastructure.
If somebody is already conducting their own tests, do let me know. As
soon as I get some free cycles, I want to run ZFS with PostgreSQL using
Solaris Express. If you have some preferred workloads do let me know.
Regards,
Jignesh
Luke Lonergan wrote:
>Juan,
>
>On 12/18/05 8:35 AM, "Juan Casero" <caseroj@comcast.net> wrote:
>
>
>
>>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 handle
a
>>database that might grow to a 100 GB. Our company is green mission
conscious
>>now so I was hoping I could use that to convince management to
consider a Sun
>>Ultrasparc T1 or T2 system provided that if I can get the best
performance
>>out of it on PostgreSQL. So will newer versions of PostgreSQL (8.1.x)
be
>>able to take of advantage of the multiple cores on a T1 or T2? I
cannot
>>change the database and this will be a hard sell unless I can convince
them
>>that the performance advantages are too good to pass up. The company
is
>>moving in the Win32 direction and so I have to provide rock solid
reasons for
>>why I want to use Solaris Sparc on a T1 or T2 server for this database
>>application instead of Windows on SQL Server.
>>
>>
>
>The Niagara CPUs are heavily multi-threaded and will require a lot of
>parallelism to be exposed to them in order to be effective.
>
>Until Sun makes niagara-based machines with lots of I/O channels, there
>won't be much I/O parallelism available to match the CPU parallelism.
>
>Bizgres MPP will use the process and I/O parallelism of these big SMP
>machines and the version based on Postgres 8.1 will be out in February.
>
>- Luke
>
>
>
>---------------------------(end of
broadcast)---------------------------
>TIP 5: don't forget to increase your free space map settings
>
>
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
^ permalink raw reply [nested|flat] 22+ messages in thread
end of thread, other threads:[~2005-12-20 19:34 UTC | newest]
Thread overview: 22+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2005-12-18 16:35 PostgreSQL and Ultrasparc T1 Juan Casero <caseroj@comcast.net>
2005-12-18 17:12 ` Christopher Petrilli <petrilli@gmail.com>
2005-12-19 07:21 ` Luke Lonergan <llonergan@greenplum.com>
2005-12-19 14:27 ` Jignesh K. Shah <J.K.Shah@Sun.COM>
2005-12-19 17:30 ` Luke Lonergan <llonergan@greenplum.com>
2005-12-19 19:29 ` Jignesh Shah <J.K.Shah@Sun.COM>
2005-12-19 19:37 ` Luke Lonergan <llonergan@greenplum.com>
2005-12-19 20:21 ` Jignesh Shah <J.K.Shah@Sun.COM>
2005-12-20 01:34 ` Luke Lonergan <llonergan@greenplum.com>
2005-12-20 01:37 ` Luke Lonergan <llonergan@greenplum.com>
2005-12-20 19:34 ` Jim C. Nasby <jnasby@pervasive.com>
2005-12-19 06:25 Re: PostgreSQL and Ultrasparc T1 Scott Marlowe <smarlowe@g2switchworks.com>
2005-12-20 00:32 ` Juan Casero <caseroj@comcast.net>
2005-12-20 04:19 ` Jignesh K. Shah <J.K.Shah@Sun.COM>
2005-12-20 15:01 ` Alan Stange <stange@rentec.com>
2005-12-20 15:08 ` David Lang <dlang@invendra.net>
2005-12-20 15:14 ` Alan Stange <stange@rentec.com>
2005-12-20 15:22 ` David Lang <dlang@invendra.net>
2005-12-20 16:50 ` Richard_D_Levine@raytheon.com
2005-12-20 17:20 ` Jignesh K. Shah <J.K.Shah@Sun.COM>
2005-12-20 19:22 ` Jim C. Nasby <jnasby@pervasive.com>
2005-12-19 15:21 Re: PostgreSQL and Ultrasparc T1 Anjan Dave <adave@vantage.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox