Re: PostgreSQL future ideas - Mailing list pgsql-hackers

From Mark Mielke
Subject Re: PostgreSQL future ideas
Date
Msg-id 48D424EC.3080101@mark.mielke.cc
Whole thread Raw
In response to Re: PostgreSQL future ideas  ("Gevik Babakhani" <pgdev@xs4all.nl>)
List pgsql-hackers
Gevik Babakhani wrote: <blockquote cite="mid:006201c91aa2$5c64bde0$0a01a8c0@gevmus" type="cite"><blockquote
type="cite"><prewrap="">I think the better question about all of this is:
 
What is the problem we are trying to solve? 
Providing solutions that are looking for problems doesn't help us.
Sincerely,   </pre></blockquote><pre wrap="">
Perhaps the current codebase and design in C will serve us for years and
years to come. In fact there is no doubt about that and switching to an OO
design is no easy task. But times change and technologies evolve. So should
any software solution that is hoping to continue and compete with other
competitors of the same kind.

Procedural programming languages like C may have been languages of choice
for many years but they gradually loose developer audience just because of
the reason above. I am afraid PG is no exception here.  </pre></blockquote><br /> A major problem I have with this
suggestionis that PostgreSQL would indeed be equivalent or better re-written in another language. All PostgreSQL
benchmarkingand design decisions have been based upon measuring the performance of PostgreSQL written in C for common
platforms.At it's most basic, if you were to do a strict 1:1 translation of PostgreSQL from C to Java, I feel confident
inguaranteeing that you will see a 10 times or more drop in performance. Why? Because what is fast in Java is not the
sameas what is fast in C. The design decisions would all need to be revisited, and the effect would be exactly as
alreadysuggested - an immature design, competing against other mature designs.<br /><br /> From C to C++ is only a
smallerleap in the sense that pieces of PostgreSQL could be migrated at a time. The result is still that an OO-modelled
PostgreSQLwould be significantly different from a procedure-modelled PostgreSQL, and you would always be facing the
compromiseof: 1) Should re-write this part to be OO? or 2) Should we leave it alone for now (and then, why bother using
C++?).<br/><br /> Somebody working on a thesis or with thousands of hours of spare time and no inclination to work on
anyother part, might prove that many of the PostgreSQL technologies port well to another language - but it is far more
likelythat the result will be a bust.<br /><br /> I'd rather core developer effort was spent doing what they are doing
today.<br/><br /> Cheers,<br /> mark<br /><pre class="moz-signature" cols="72">-- 
 
Mark Mielke <a class="moz-txt-link-rfc2396E" href="mailto:mark@mielke.cc"><mark@mielke.cc></a>
</pre>

pgsql-hackers by date:

Previous
From: Martijn van Oosterhout
Date:
Subject: Re: WIP patch: Collation support
Next
From: Andrew Chernow
Date:
Subject: Re: PostgreSQL future ideas