On Wed, Aug 10, 2005 at 09:16:08AM -0700, Luke Lonergan wrote:
> On 8/10/05 8:37 AM, "Tom Lane" <[EMAIL PROTECTED]> wrote:
> > Luke, I dislike whacking people upside the head, but this discussion
> > seems to presume that raw speed on Intel platforms is the only thing
> > that matters. We have a few other concerns. Portability, readability,
> > maintainability, and correctness all trump platform-specific
> > optimizations. The COPY patch as presented lost badly on all those
> > counts, and you are lucky that it didn't get rejected completely.
> It's a pleasure working with you too Tom :-)
> Until you present a result on platform that is faster than Alon's in the
> code that was modified, our proof still stands that his is 20% faster than
AFAIR he never claimed otherwise ... his point was that to gain that
additional speedup, the code has to be made considerable "worse" (in
maintenability terms.) Have you (or Alon) tried to port the rest of the
speed improvement to the new code? Maybe it's possible to have at least
some of it without worsening the maintenability too badly.
Another question that comes to mind is: have you tried another compiler?
I see you are all using GCC at most 3.4; maybe the new optimizing
infrastructure in GCC 4.1 means you can have most of the speedup without
uglifying the code. What about Intel's compiler?
> PostgreSQL needs major improvement to compete with Oracle and even MySQL on
> speed. No whacking on the head is going to change that.
Certainly. I think the point is what cost do we want to pay for the
speedup. I think we all agree that even if we gain a 200% speedup by
rewriting COPY in assembly, it's simply not acceptable.
Another point may be that Bizgres can have a custom patch for the extra
speedup, without inflicting the maintenance cost on the community.
Alvaro Herrera (<alvherre[a]alvh.no-ip.org>)
"La libertad es como el dinero; el que no la sabe emplear la pierde" (Alvarez)
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not