UltraSPARC versus AMD
I just got done comparing SPECMarks (on spec.org) between Sun's AMD entry
level servers versus similarly configured UltraSPARCs versus desktop AMD
based machines. Sun's AMD machines are twice as fast as their UItraSPARCs,
for approximately the same price. What a hoot.
Rick
On Fri, 2005-04-22 at 09:48, Richard_D_Levine@raytheon.com wrote:
I just got done comparing SPECMarks (on spec.org) between Sun's AMD entry
level servers versus similarly configured UltraSPARCs versus desktop AMD
based machines. Sun's AMD machines are twice as fast as their UItraSPARCs,
for approximately the same price. What a hoot.
Wow. I'd certainly like to see the numbers and such from your
benchmarks. I have to say I'm not surprised, the 64 bit AMD chips are
quite impressive pieces of hardware.
pgsql-general-owner@postgresql.org wrote on 04/22/2005 10:08:46 AM:
On Fri, 2005-04-22 at 09:48, Richard_D_Levine@raytheon.com wrote:
I just got done comparing SPECMarks (on spec.org) between Sun's AMD
entry
level servers versus similarly configured UltraSPARCs versus desktop
AMD
based machines. Sun's AMD machines are twice as fast as their
UItraSPARCs,
for approximately the same price. What a hoot.
Wow. I'd certainly like to see the numbers and such from your
benchmarks. I have to say I'm not surprised, the 64 bit AMD chips are
quite impressive pieces of hardware.
The benchmarks aren't mine, they're standard performance evaluation (SPEC)
defined by spec.org
Click on the desired benchmark (I was referring to the CPU benchmarks) and
click on "published results".
The manufacturers (Sun, Dell, HP, etc.) buy the benchmarks, configure their
best compiler for speed, run them, and submit the results. My point is
that Sun ran the benchmarks, under very strict rules set forth by SPEC.
Rick
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if
your
Show quoted text
joining column's datatypes do not match
Richard_D_Levine@raytheon.com wrote:
I just got done comparing SPECMarks (on spec.org) between Sun's AMD entry
level servers versus similarly configured UltraSPARCs versus desktop AMD
based machines. Sun's AMD machines are twice as fast as their UItraSPARCs,
for approximately the same price. What a hoot.
Not that surprising. UltraSparcs haven't been "fast" in a long time.
They just scale really well.
Sincerely,
Joshua D. Drake
Rick
---------------------------(end of broadcast)---------------------------
TIP 3: 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
--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedication Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
Richard_D_Levine@raytheon.com writes:
I just got done comparing SPECMarks (on spec.org) between Sun's AMD entry
level servers versus similarly configured UltraSPARCs versus desktop AMD
based machines. Sun's AMD machines are twice as fast as their UItraSPARCs,
for approximately the same price. What a hoot.
It's not surprising.
The "interesting" efforts that Sun has been putting into CPUs lately
have gone into the new "Niagara" thing which isn't going into low end
UltraSPARCs.
AMD has gotten a lot of the ex-Digital folk, and ex-Alpha
technologies, and has been able to get that stuff into lower priced
systems, from whence is what we can see...
--
(format nil "~S@~S" "cbbrowne" "acm.org")
http://www.ntlug.org/~cbbrowne/sap.html
Rules of the Evil Overlord #78. "I will not tell my Legions of Terror
"And he must be taken alive!" The command will be: ``And try to take
him alive if it is reasonably practical.''"
<http://www.eviloverlord.com/>
Chris Browne wrote:
Richard_D_Levine@raytheon.com writes:
I just got done comparing SPECMarks (on spec.org) between Sun's AMD entry
level servers versus similarly configured UltraSPARCs versus desktop AMD
based machines. Sun's AMD machines are twice as fast as their UItraSPARCs,
for approximately the same price. What a hoot.
The focus should not just be on SPARC vs AMD64. The AMD64 chips
outperform Intel P4 and Xeon handily as well, using ooomph per
dollar, oooomph per Megahertz, or most other measures. I'm
certainly not complaining, it just appears AMD64 is an outstanding
value these days.
We purchased 2 laptops, one P4, one AMD64 from a linux-friendly
vendor to use as software demo boxes. The AMD CPU speed is about
60% of the Intel P4 CPU speed, both have same amount of RAM & Disk,
both have the same video controller. The intel laptop was more
expensive, but the AMD64 box clearly outperforms it with both
postgresql and our weather/flight tracking applications.
Josh
Aceshardware.com has a good UI for looking at Spec scores. They imported
all the results into their DB for easily comparisons between processors.
Single CPU (individual queries):
Quad CPU SMP performance:
Money is no object performance:
The numbers don't have the latest dual core Opterons yet. (Don't see
them on spec.org yet either.) My random guess right now, 4x2 system
would probably be about 140 SpecINT_rate. It's looking like it's faster
than have a DC Opteron w/ 1 memory bank versus Dual Opteron w/ 2 memory
bank because the interconnect between cores inside a DC CPU is so much
faster than the HT motherboard connect.
Richard_D_Levine@raytheon.com wrote:
Show quoted text
pgsql-general-owner@postgresql.org wrote on 04/22/2005 10:08:46 AM:
On Fri, 2005-04-22 at 09:48, Richard_D_Levine@raytheon.com wrote:
I just got done comparing SPECMarks (on spec.org) between Sun's AMD
entry
level servers versus similarly configured UltraSPARCs versus desktop
AMD
based machines. Sun's AMD machines are twice as fast as their
UItraSPARCs,
for approximately the same price. What a hoot.
Wow. I'd certainly like to see the numbers and such from your
benchmarks. I have to say I'm not surprised, the 64 bit AMD chips are
quite impressive pieces of hardware.The benchmarks aren't mine, they're standard performance evaluation (SPEC)
defined by spec.orgClick on the desired benchmark (I was referring to the CPU benchmarks) and
click on "published results".The manufacturers (Sun, Dell, HP, etc.) buy the benchmarks, configure their
best compiler for speed, run them, and submit the results. My point is
that Sun ran the benchmarks, under very strict rules set forth by SPEC.Rick
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan ifyour
joining column's datatypes do not match
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
Looked on AMD's website. 132 for 4x875 on Windows, 126 on Linux.
(Probably Intel compiler on Windows, gcc on Linux.) That gets AMD into
the $100K 16+ processor Sun system area in terms of performance. Of
course, Sun still has a crapload of other uptime/reliability features
built-in to their systems.
William Yu wrote:
Show quoted text
The numbers don't have the latest dual core Opterons yet. (Don't see
them on spec.org yet either.) My random guess right now, 4x2 system
would probably be about 140 SpecINT_rate. It's looking like it's faster
than have a DC Opteron w/ 1 memory bank versus Dual Opteron w/ 2 memory
bank because the interconnect between cores inside a DC CPU is so much
faster than the HT motherboard connect.
Well, you overlook one thing there. SUN has always has a really good I/O
performance - something far from negligible for a database application.
A lot of the PC systems lack that kind of I/O thruput.
Just compare a simple P4 with ATAPI drives to the same P4 with 320 SCSI drives
- the speed difference, particularly using any *nix, is surprisingly
significant and easily visible with the bare eye.
There is a reason why a lot of the financial/insurance institutions (having a
lot of transactions in their DB applications) use either IBM mainframes or
SUN E10k's :-)
Personally I think a weaker processor with top of the line I/O will perform
better for DB apps than the fastest processor with crappy I/O.
i guess the "my $0.02" is in order here :-)
UC
On Saturday 23 April 2005 01:06, William Yu wrote:
Looked on AMD's website. 132 for 4x875 on Windows, 126 on Linux.
(Probably Intel compiler on Windows, gcc on Linux.) That gets AMD into
the $100K 16+ processor Sun system area in terms of performance. Of
course, Sun still has a crapload of other uptime/reliability features
built-in to their systems.William Yu wrote:
The numbers don't have the latest dual core Opterons yet. (Don't see
them on spec.org yet either.) My random guess right now, 4x2 system
would probably be about 140 SpecINT_rate. It's looking like it's faster
than have a DC Opteron w/ 1 memory bank versus Dual Opteron w/ 2 memory
bank because the interconnect between cores inside a DC CPU is so much
faster than the HT motherboard connect.---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
--
Open Source Solutions 4U, LLC 2570 Fleetwood Drive
Phone: +1 650 872 2425 San Bruno, CA 94066
Cell: +1 650 302 2405 United States
Fax: +1 650 872 2417
Oh I'm sure in the past, Sun had way better I/O performance. But the gap
at least for entry-level servers has closed quite a lot with HT,
Inifiband, PCI-X, PCIe and so on available on for x86. Most x86 2P/4P
server MBs I've seen seem to have 2 PCI-X bridges, 1 PCI bridge and
separate bridges for 2x Gigabit Ethernet -- easily 2+GB of I/O available.
Now the latest craze is PCIe. For example, the Tyan S2895 has 3 HT
(6.4GB/s) connections used for I/O. #1 has PCIe x16 (8GB) + GigE, #2 has
PCIe x16 + GigE + SATA + IDE, #3 has PCI-X 133 (1GB) + PCI-X 100 (.75GB)
+ PCI. If you could find the right cards to max out the system, we're
looking at 14+ GB/s of I/O. Unfortunately, the PCIe SCSI RAID controller
selection is pretty sparse right now. There's a PCIe x8 (4GB/s) card
from Intel but it's only has 2 U320 channels so it's way underutilizing
the available bandwidth.
As for why financial/insurance institutions use IBMs or Suns -- I would
suggest limited choice is a bigger issue than any specific sub-system
performance factor. A nationwide bank doesn't have any choice except to
pick a monster 100+ processor machine because anything slower couldn't
handle their 20,000 employees. Not many options really. Plus, people in
big companies tend to make safe decisions -- get the company with the
most name value so you don't get fired if the machine turns out to be a
lemon.
Uwe C. Schroeder wrote:
Show quoted text
Well, you overlook one thing there. SUN has always has a really good I/O
performance - something far from negligible for a database application.
A lot of the PC systems lack that kind of I/O thruput.
Just compare a simple P4 with ATAPI drives to the same P4 with 320 SCSI drives
- the speed difference, particularly using any *nix, is surprisingly
significant and easily visible with the bare eye.
There is a reason why a lot of the financial/insurance institutions (having a
lot of transactions in their DB applications) use either IBM mainframes or
SUN E10k's :-)
Personally I think a weaker processor with top of the line I/O will perform
better for DB apps than the fastest processor with crappy I/O.i guess the "my $0.02" is in order here :-)
UC
On Saturday 23 April 2005 01:06, William Yu wrote:
Looked on AMD's website. 132 for 4x875 on Windows, 126 on Linux.
(Probably Intel compiler on Windows, gcc on Linux.) That gets AMD into
the $100K 16+ processor Sun system area in terms of performance. Of
course, Sun still has a crapload of other uptime/reliability features
built-in to their systems.William Yu wrote:
The numbers don't have the latest dual core Opterons yet. (Don't see
them on spec.org yet either.) My random guess right now, 4x2 system
would probably be about 140 SpecINT_rate. It's looking like it's faster
than have a DC Opteron w/ 1 memory bank versus Dual Opteron w/ 2 memory
bank because the interconnect between cores inside a DC CPU is so much
faster than the HT motherboard connect.---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)--
Open Source Solutions 4U, LLC 2570 Fleetwood Drive
Phone: +1 650 872 2425 San Bruno, CA 94066
Cell: +1 650 302 2405 United States
Fax: +1 650 872 2417---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
As someone who works in a nationwide bank, let me tell you why we
choose IBM and Sun hardware: support. If we want to get a server for a
project, we can't just go get the most cost-efficient thing out there
for the job. We have a short list of servers that can be picked from,
and that's it. A given server makes it onto that list if and only if it
can be supported by a vendor in a matter of hours for at least 3 years.
We don't always purchase that support, but bank policy says it has to
be an option.
We don't generally purchase monster machines. Sure, there are some
mainframes, but they are few and far between. Everything else doesn't
really have anything more than 32 procs.
On Apr 23, 2005, at 2:58 AM, William Yu wrote:
Show quoted text
As for why financial/insurance institutions use IBMs or Suns -- I
would suggest limited choice is a bigger issue than any specific
sub-system performance factor. A nationwide bank doesn't have any
choice except to pick a monster 100+ processor machine because
anything slower couldn't handle their 20,000 employees. Not many
options really. Plus, people in big companies tend to make safe
decisions -- get the company with the most name value so you don't get
fired if the machine turns out to be a lemon.
32 proc IBM boxes > 100+ SUN boxes. :)
Ben wrote:
Show quoted text
We don't generally purchase monster machines. Sure, there are some
mainframes, but they are few and far between. Everything else doesn't
really have anything more than 32 procs.
I am looking at options for a customer with an installed base of ~5000 Sun
workstations running 400-500MHz UltraSPARCs. They're not getting the
performance they need. They shipped me two Tadpole Bullfrog machines, a
Bullfrog I and a Bullfrog II for evaluation.
1.28GHz single or dual CPU UltraSPARCs. On board SCSI, but they installed
IDE drives instead.
In my *utter* lack of enthusiasm over this option, I was gathering
ammunition for better hardware. I went to spec.org for speed comparisons,
and sun.com for price comparisons. Sun's *entry* level servers are more
powerful when running AMD CPUs.
I note with interest and appreciation comments about the bigger iron from
Sun and IBM. That's not what I'm in the market for, but good info as
always.
My evaluation is that a single or dual core AMD 64 Athlon in a rugged
laptop is going to give a performance enhancement (SPECMark wise) of about
an order of magnitude over their current hardware base. And it's cheaper.
The current hardware base contains a 10k SCSI Fast Wide Ultra single disk
on a 440MHz CPU as well as a 7200 IDE on a 500MHz CPU. The SCSI with the
slower CPU runs the application 8% faster. Obviously I'll need to work on
the proper I/O subsystem because that's apparently more of a limiter than
the CPU speed.
Cheers,
Rick
pgsql-general-owner@postgresql.org wrote on 04/23/2005 11:02:17 AM:
Show quoted text
As someone who works in a nationwide bank, let me tell you why we
choose IBM and Sun hardware: support. If we want to get a server for a
project, we can't just go get the most cost-efficient thing out there
for the job. We have a short list of servers that can be picked from,
and that's it. A given server makes it onto that list if and only if it
can be supported by a vendor in a matter of hours for at least 3 years.
We don't always purchase that support, but bank policy says it has to
be an option.We don't generally purchase monster machines. Sure, there are some
mainframes, but they are few and far between. Everything else doesn't
really have anything more than 32 procs.On Apr 23, 2005, at 2:58 AM, William Yu wrote:
As for why financial/insurance institutions use IBMs or Suns -- I
would suggest limited choice is a bigger issue than any specific
sub-system performance factor. A nationwide bank doesn't have any
choice except to pick a monster 100+ processor machine because
anything slower couldn't handle their 20,000 employees. Not many
options really. Plus, people in big companies tend to make safe
decisions -- get the company with the most name value so you don't get
fired if the machine turns out to be a lemon.---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
On Sat, 23 Apr 2005, Uwe C. Schroeder wrote:
Well, you overlook one thing there. SUN has always has a really good I/O
performance - something far from negligible for a database application.
A lot of the PC systems lack that kind of I/O thruput.
Just compare a simple P4 with ATAPI drives to the same P4 with 320 SCSI drives
- the speed difference, particularly using any *nix, is surprisingly
significant and easily visible with the bare eye.
There is a reason why a lot of the financial/insurance institutions (having a
lot of transactions in their DB applications) use either IBM mainframes or
SUN E10k's :-)
Personally I think a weaker processor with top of the line I/O will perform
better for DB apps than the fastest processor with crappy I/O.i guess the "my $0.02" is in order here :-)
Given that "basic" SQL is getting more analytical in capability, esp if
you look at PostGIS/Postgres or Oracle/Informix/DB2 with their respective
spatial extensions, then spatial overlays with several tables with
polygons with large no's of vertices can get cpu bound as well as the more
traditional DB I/O bound limitations.
But, I agree that generally I/O is a more typical db issue.
Brent Wood
Richard_D_Levine@raytheon.com wrote:
In my *utter* lack of enthusiasm over this option, I was gathering
ammunition for better hardware. I went to spec.org for speed comparisons,
and sun.com for price comparisons. Sun's *entry* level servers are more
powerful when running AMD CPUs.
Just in case people still hold a bias against CISC processors capable of
running x86 code as necessarily inferior to more expensive 64-bit RISC
processors, in spite of the overwhelmingly obvious specint results to
the contrary, I'd like to offer up this little baby:
http://www.cray.com/products/xt3/index.html
Something everyone should have in their office...
Mike Mascari
Mike Mascari <mascarm@mascari.com> wrote on 04/25/2005 09:21:02 PM:
Richard_D_Levine@raytheon.com wrote:
In my *utter* lack of enthusiasm over this option, I was gathering
ammunition for better hardware. I went to spec.org for speed
comparisons,
and sun.com for price comparisons. Sun's *entry* level servers are
more
powerful when running AMD CPUs.
Just in case people still hold a bias against CISC processors capable of
running x86 code as necessarily inferior to more expensive 64-bit RISC
processors, in spite of the overwhelmingly obvious specint results to
the contrary, I'd like to offer up this little baby:http://www.cray.com/products/xt3/index.html
Something everyone should have in their office...
I RTFA. Oh my god. Favorite excerpts:
AMD Opteron Processor
The industry leading Opteron microprocessor offers a number of advantages
for superior performance and scalability.
The Opteron processor's on-chip, highly associative 1 MB cache supports
aggressive out-of-order execution and can issue up to nine instructions
simultaneously. The integrated memory controller eliminates the need for a
separate Northbridge memory controller chip, providing an extremely low
latency path to local memory—less than 60 nanoseconds. This is a
significant performance advantage, particularly for algorithms that require
irregular memory access. The 128-bit wide memory controller provides 6.4
GB/s local memory bandwidth per processor, or more than one byte per
FLOP. This balance brings a performance advantage to algorithms that stress
local memory bandwidth.
Service PEs run a full Linux™ distribution. Service PEs can be configured
to provide login, I/O, system, or network services.
Scalable Operating System
The Cray XT3 operating system UNICOS/lc is designed to run large complex
applications and scale efficiently to 30,000 processors.
The I/O architecture consists of data RAIDs connected directly to I/O PEs
which reside on the high-speed interconnect. The Lustre file system manages
the striping of file operations across these RAIDs.
Show quoted text
Mike Mascari
-----Original Message-----
From: pgsql-general-owner@postgresql.org
[mailto:pgsql-general-owner@postgresql.org]On Behalf Of Brent Wood
Sent: Monday, April 25, 2005 8:20 PM
To: Uwe C. Schroeder
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] UltraSPARC versus AMDOn Sat, 23 Apr 2005, Uwe C. Schroeder wrote:
Well, you overlook one thing there. SUN has always has a
really good I/O
performance - something far from negligible for a database
application.
Am i dreaming?,
Solaris really good I/O performance?
Have your heard of slowlaris?
May be you mean hardware performance, combined with a great OS (BSD or
Linux)
I had to "upgrade" many Sunfire 280 (running slowlaris [8|9]) to BSD because
of poor DB performance, after the upgrade, all run flawlessly.
I only wish a had made this switch before
Just my $0.02
A lot of the PC systems lack that kind of I/O thruput.
Just compare a simple P4 with ATAPI drives to the same P4with 320 SCSI drives
- the speed difference, particularly using any *nix, is surprisingly
significant and easily visible with the bare eye.
We are talking about server or pc?, we run postgres on several HP dl380 (5i
SCSI controller) with great performance
There is a reason why a lot of the financial/insurance
institutions (having a
lot of transactions in their DB applications) use either
IBM mainframes or
SUN E10k's :-)
Personally I think a weaker processor with top of the lineI/O will perform
better for DB apps than the fastest processor with crappy I/O.
i guess the "my $0.02" is in order here :-)
i totally agree with this
---
Miguel
Import Notes
Resolved by subject fallback
pgsql-general-owner@postgresql.org wrote on 04/25/2005 09:19:57 PM:
On Sat, 23 Apr 2005, Uwe C. Schroeder wrote:
Well, you overlook one thing there. SUN has always has a really good
I/O
performance - something far from negligible for a database application.
A lot of the PC systems lack that kind of I/O thruput.
Just compare a simple P4 with ATAPI drives to the same P4 with 320SCSI drives
- the speed difference, particularly using any *nix, is surprisingly
significant and easily visible with the bare eye.
There is a reason why a lot of the financial/insuranceinstitutions (having a
lot of transactions in their DB applications) use either IBM mainframes
or
SUN E10k's :-)
Personally I think a weaker processor with top of the line I/O will
perform
better for DB apps than the fastest processor with crappy I/O.
i guess the "my $0.02" is in order here :-)
Given that "basic" SQL is getting more analytical in capability, esp if
you look at PostGIS/Postgres or Oracle/Informix/DB2 with their respective
spatial extensions, then spatial overlays with several tables with
polygons with large no's of vertices can get cpu bound as well as the
more
traditional DB I/O bound limitations.
But, I agree that generally I/O is a more typical db issue.
I also agree that I/O is the bigger problem, but for me the bottom line is
that there has been a power/price inversion in CPUs. AMD chips are cheaper
and more powerful than Intel, which are cheaper and more powerful than
lower-end UltraSPARCs. I can't speak for higher-end UltraSPARCs (someone
mentioned a Niagara chip, which may or may not be the new UltraSPARC IV.)
I think it speaks volumes that Cray's top of the line machine uses 30,000
Opterons with 240 *terabytes* of RAM (8GB/CPU).
I also agree that spatial DB operations are compute intensive for floating
point trigonometric functions, so why not put the cheapest and best in a
low-end server, especially a map server? If someone mentions $7k again....
Rick
Brent Wood
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if
your
Show quoted text
joining column's datatypes do not match
Sun's stock was at $65.00 in late 2000 and has rocketed to $3.50. I think
somebody else besides us noticed too.
pgsql-general-owner@postgresql.org wrote on 04/26/2005 01:12:49 PM:
-----Original Message-----
From: pgsql-general-owner@postgresql.org
[mailto:pgsql-general-owner@postgresql.org]On Behalf Of Brent Wood
Sent: Monday, April 25, 2005 8:20 PM
To: Uwe C. Schroeder
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] UltraSPARC versus AMDOn Sat, 23 Apr 2005, Uwe C. Schroeder wrote:
Well, you overlook one thing there. SUN has always has a
really good I/O
performance - something far from negligible for a database
application.
Am i dreaming?,
Solaris really good I/O performance?Have your heard of slowlaris?
May be you mean hardware performance, combined with a great OS (BSD or
Linux)I had to "upgrade" many Sunfire 280 (running slowlaris [8|9]) to BSD
because
of poor DB performance, after the upgrade, all run flawlessly.
I only wish a had made this switch before
Just my $0.02A lot of the PC systems lack that kind of I/O thruput.
Just compare a simple P4 with ATAPI drives to the same P4with 320 SCSI drives
- the speed difference, particularly using any *nix, is surprisingly
significant and easily visible with the bare eye.We are talking about server or pc?, we run postgres on several HP dl380
(5i
SCSI controller) with great performance
There is a reason why a lot of the financial/insurance
institutions (having a
lot of transactions in their DB applications) use either
IBM mainframes or
SUN E10k's :-)
Personally I think a weaker processor with top of the lineI/O will perform
better for DB apps than the fastest processor with crappy I/O.
i guess the "my $0.02" is in order here :-)
i totally agree with this
---
Miguel---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if
your
Show quoted text
joining column's datatypes do not match