Thread: PostgreSQL 8.0 Feature List?
Looking forward to PostgreSQL 8.0 :). Is there an "official" feature list? What I've dug up so far: nested transactions transaction checkpoints point in time recovery tablespaces native Windows port plpgsql exceptions integrated pg_autovacuum ARC buffer code? Thanks, CSN __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On Sun, 2004-08-08 at 22:37, CSN wrote: > Looking forward to PostgreSQL 8.0 :). Is there an > "official" feature list? What I've dug up so far: > > nested transactions > transaction checkpoints > point in time recovery > tablespaces > native Windows port > plpgsql exceptions > integrated pg_autovacuum > ARC buffer code? pg_autovacuum didn't quite make it, and will remain contrib. Maybe 8.1 or so. Also add: New background writer process. The ability to set vacuum delay for heavily loaded databases. Log rotation.
On 8 Aug 2004 at 21:37, CSN wrote: > native Windows port I thought this one was coming with 7.5? --Ray. ------------------------------------------------------------- Raymond O'Donnell http://www.galwaycathedral.org/recitals rod@iol.ie Galway Cathedral Recitals -------------------------------------------------------------
Raymond O'Donnell wrote: > On 8 Aug 2004 at 21:37, CSN wrote: > > >>native Windows port > > > I thought this one was coming with 7.5? 7.5 was renamed to 8.0 Regards Gaetano Mendola
CSN wrote:
> Looking forward to PostgreSQL 8.0 :). Is there an
> "official" feature list? What I've dug up so far:
>
> nested transactions
> transaction checkpoints
> point in time recovery
> tablespaces
> native Windows port
> plpgsql exceptions
> integrated pg_autovacuum
> ARC buffer code?
Please look at the release notes as part of the docs on the developers
web site:
http://developer.postgresql.org
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Will PostgreSQL 8.0 include replication server (not contrib/*) and nested transactions support? -- WBR, sector119
Am Dienstag, 10. August 2004 10:05 schrieb sector119@mail.ru: > Will PostgreSQL 8.0 include replication server (not contrib/*) and nested > transactions support? No and yes. -- Peter Eisentraut http://developer.postgresql.org/~petere/
On Tue, 2004-08-10 at 02:05, sector119@mail.ru wrote: > Will PostgreSQL 8.0 include replication server (not contrib/*) and nested transactions support? What difference does it make if replication is contrib/* or an external project or integrated? It's still the same thing. Plus, there are currently no replication systems for postgresql that are all things to all people, hence none are included or likely to be included. Slony-I just came out in beta, and it appears to be quite a nice replication system. To put it bluntly, which would you rather have, a database with integrated replication that had a flawed / unreliable replication system, or a database with an external replication system that works flawlessly? Integration is much less important than whether it functions, and anyone who says otherwise has been drinking too much marketing kool aid. nested transactions / savepoints will be included.
Scott Marlowe wrote: > On Tue, 2004-08-10 at 02:05, sector119@mail.ru wrote: > >> Will PostgreSQL 8.0 include replication server (not contrib/*) >> and nested transactions support? > > > Slony-I just came out in beta, and it appears to be quite a nice > replication system. I wonder if it would be a good idea from a propaganda perspective to include a reference to Slony-I in the press release and possibly the release notes? Or would such an imprimatur be inappropriate? Also, what is the etymology of the term Slony? Mike Mascari
As to Slony: in a few slavonic languages (I know about Czech, Slovak, Russian, maybe others too, "slony" is the plural of "slon", e.g. elephant. Thus Slony = Elephants. Cheers Zoltan Dňa Utorok 10. August 2004 11:51 ste napísali: > Scott Marlowe wrote: > > On Tue, 2004-08-10 at 02:05, sector119@mail.ru wrote: > >> Will PostgreSQL 8.0 include replication server (not contrib/*) > >> and nested transactions support? > > > > Slony-I just came out in beta, and it appears to be quite a nice > > replication system. > > I wonder if it would be a good idea from a propaganda perspective to > include a reference to Slony-I in the press release and possibly the > release notes? Or would such an imprimatur be inappropriate? > > Also, what is the etymology of the term Slony? > > Mike Mascari > > > ---------------------------(end of broadcast)--------------------------- > TIP 7: don't forget to increase your free space map settings
Am Dienstag, 10. August 2004 11:51 schrieb Mike Mascari: > I wonder if it would be a good idea from a propaganda perspective to > include a reference to Slony-I in the press release and possibly the > release notes? Or would such an imprimatur be inappropriate? It will probably be in the press release, but not in the release notes. > Also, what is the etymology of the term Slony? Russian: slon = elephant slony = elephants -- Peter Eisentraut http://developer.postgresql.org/~petere/
On Tue, 10 Aug 2004 03:17:00 -0600 Scott Marlowe <smarlowe@qwest.net> wrote:
> Plus, there are
> currently no replication systems for postgresql that are all things to
> all people,
is this even possible?
(no, don't answer that, it's a rhetorical question.)
i can make a case that there are at least 3 distinctly different types
of replication needed depending on the application.
1) synchronous
2) single master, multiple slave asynchronous
(aka slony)
3) multi-master async w/conflict resolution
(like the now woefully out of date pg-replicator)
the work on slony is appreciated, but i need 3), and it
looks like i'm going to have to do it myself. sigh.
richard
--
Richard Welty rwelty@averillpark.net
Averill Park Networking 518-573-7592
Java, PHP, PostgreSQL, Unix, Linux, IP Network Engineering, Security
On 8/10/2004 5:51 AM, Mike Mascari wrote: > Scott Marlowe wrote: > >> On Tue, 2004-08-10 at 02:05, sector119@mail.ru wrote: >> >>> Will PostgreSQL 8.0 include replication server (not contrib/*) >>> and nested transactions support? >> >> >> Slony-I just came out in beta, and it appears to be quite a nice >> replication system. Slony-I is released and we will follow up with a 1.0.2 that will support PostgreSQL 8.0beta1 this week, so that people can test replicating their 7.x databases to 8.0 in preparation of upgrade switchover. > I wonder if it would be a good idea from a propaganda perspective to > include a reference to Slony-I in the press release and possibly the > release notes? Or would such an imprimatur be inappropriate? The Slony team would appreciate this, but I think pointing to one project only is inappropriate, given the current marketshare situation. The marketshare should change quickly, because Slony-I is a highly active project, as the instant 8.0 support demonstrates (CVS tip and REL_1_0_STABLE branch run with 8.0beta1 so the 1.0.2 release is more or less wrapping a tarball), while other replication projects are seriously behind the release schedule. A fact that contradicts the ever so often made claim that an integrated solution would have release schedule or maintenance advantages. I cannot see the disadvantages of an external project in this case. However, replication is a top priority question and the press release for 8.0 must address this. The more so because PostgreSQL seems to be the only database that for good reasons does not come with a bundled or builtin replication thingy, but rather relies on the diversity and specialization of related projects. > > Also, what is the etymology of the term Slony? Elephants, especially this one: http://slony.info Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
At 8/10/04 9:30 AM, JanWieck@Yahoo.com wrote: >Slony-I is released... [snip] > >> >> Also, what is the etymology of the term Slony? > >Elephants, especially this one: http://slony.info Is the project called "Slony-1" or "Slony1" (numeral one), or "Slony-I" (uppercase i)? It appears to be referred to multiple ways, even on the Web site, which means that it's difficult to search for and I don't know how to pronounce it when I talk to other people. (I'm convinced that hard-to-pronounce names make people decide not to mention cool things to other people for fear they'll look stupid, directly resulting in less word-of-mouth.) -- Robert L Mathews, Tiger Technologies http://www.tigertech.net/ "Ignorance more frequently begets confidence than does knowledge." -- Darwin
On Tue, 2004-08-10 at 07:51, Richard Welty wrote:
> On Tue, 10 Aug 2004 03:17:00 -0600 Scott Marlowe <smarlowe@qwest.net> wrote:
> > Plus, there are
> > currently no replication systems for postgresql that are all things to
> > all people,
>
> is this even possible?
>
> (no, don't answer that, it's a rhetorical question.)
>
> i can make a case that there are at least 3 distinctly different types
> of replication needed depending on the application.
>
> 1) synchronous
>
> 2) single master, multiple slave asynchronous
> (aka slony)
>
> 3) multi-master async w/conflict resolution
> (like the now woefully out of date pg-replicator)
>
> the work on slony is appreciated, but i need 3), and it
> looks like i'm going to have to do it myself. sigh.
>
On the upside, you have already been given pg-replicator as a starting
point, all you need to do is being it up to speed.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
On 11 Aug 2004 13:51:49 -0400 Robert Treat <xzilla@users.sourceforge.net> wrote:
> On the upside, you have already been given pg-replicator as a starting
> point, all you need to do is being it up to speed.
i have to rewrite it in a different language. it depends on tcl-dp, an unsupported
(and reportedly flakey) variant on tcl.
i'm quite experienced in C and Java, so it's going to be in one of those two.
any comments from anyone on the language choice?
sigh,
richard
--
Richard Welty rwelty@averillpark.net
Averill Park Networking 518-573-7592
Java, PHP, PostgreSQL, Unix, Linux, IP Network Engineering, Security
>>>>> "RW" == Richard Welty <rwelty@averillpark.net> writes: RW> i'm quite experienced in C and Java, so it's going to be in one of RW> those two. any comments from anyone on the language choice? eRServer is written in Java. It sucks up about 200Mb+ virtual memory for a teeny-tiny little database. I'd avoid java :-) -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D. Khera Communications, Inc. Internet: khera@kciLink.com Rockville, MD +1-301-869-4449 x806 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
On Thu, 12 Aug 2004, Vivek Khera wrote: >>>>>> "RW" == Richard Welty <rwelty@averillpark.net> writes: > > RW> i'm quite experienced in C and Java, so it's going to be in one of > RW> those two. any comments from anyone on the language choice? > > > eRServer is written in Java. It sucks up about 200Mb+ virtual memory > for a teeny-tiny little database. I'd avoid java :-) We felt the same way, that's why we've been working at re-writing it in C++ ... new version is currently going into beta testing, so should hopefully be available RSN ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Thu, 12 Aug 2004 14:36:13 -0400 Vivek Khera <khera@kcilink.com> wrote:
> >>>>> "RW" == Richard Welty <rwelty@averillpark.net> writes:
> RW> i'm quite experienced in C and Java, so it's going to be in one of
> RW> those two. any comments from anyone on the language choice?
> eRServer is written in Java. It sucks up about 200Mb+ virtual memory
> for a teeny-tiny little database. I'd avoid java :-)
java often sucks up too much memory. java doesn't have to suck
up too much memory, it just usually gets written that way.
richard
--
Richard Welty rwelty@averillpark.net
Averill Park Networking 518-573-7592
Java, PHP, PostgreSQL, Unix, Linux, IP Network Engineering, Security
Scott Marlowe wrote: > On Tue, 2004-08-10 at 02:05, sector119@mail.ru wrote: > >>Will PostgreSQL 8.0 include replication server (not contrib/*) and nested transactions support? > > > > nested transactions / savepoints will be included. > > what is a nested transaction?
Tom Allison wrote:
> Scott Marlowe wrote:
> > On Tue, 2004-08-10 at 02:05, sector119@mail.ru wrote:
> >
> >>Will PostgreSQL 8.0 include replication server (not contrib/*) and nested transactions support?
> >
> > >
> > nested transactions / savepoints will be included.
> >
> >
>
> what is a nested transaction?
BEGIN;
BEGIN;
COMMIT;
COMMIT;
We later decided to just support savepoints.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
On 8/12/2004 8:53 PM, Richard Welty wrote: > On Thu, 12 Aug 2004 14:36:13 -0400 Vivek Khera <khera@kcilink.com> wrote: >> >>>>> "RW" == Richard Welty <rwelty@averillpark.net> writes: >> RW> i'm quite experienced in C and Java, so it's going to be in one of >> RW> those two. any comments from anyone on the language choice? > >> eRServer is written in Java. It sucks up about 200Mb+ virtual memory >> for a teeny-tiny little database. I'd avoid java :-) > > java often sucks up too much memory. java doesn't have to suck > up too much memory, it just usually gets written that way. Right. The garbage collection automatically taking care of unreferenced objects as a stop-gap for resource leakage is abused by lazy programmers as a general purpose cleanup mechanism. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
On Sat, 14 Aug 2004 12:03:21 -0400 Jan Wieck <JanWieck@Yahoo.com> wrote:
> On 8/12/2004 8:53 PM, Richard Welty wrote:
> > On Thu, 12 Aug 2004 14:36:13 -0400 Vivek Khera <khera@kcilink.com> wrote:
> >> >>>>> "RW" == Richard Welty <rwelty@averillpark.net> writes:
> >> RW> i'm quite experienced in C and Java, so it's going to be in one of
> >> RW> those two. any comments from anyone on the language choice?
> >
> >> eRServer is written in Java. It sucks up about 200Mb+ virtual memory
> >> for a teeny-tiny little database. I'd avoid java :-)
> >
> > java often sucks up too much memory. java doesn't have to suck
> > up too much memory, it just usually gets written that way.
> Right. The garbage collection automatically taking care of unreferenced
> objects as a stop-gap for resource leakage is abused by lazy programmers
> as a general purpose cleanup mechanism.
some of it is this, certainly. some of it is bad education.
i was a professional lisp programmer for some 10+ years. lisp, of
course, has the ancestral garbage collection scheme, and the
lisp garbage collectors at this juncture are very, very, very good,
much more mature than java's garbage collector. nonetheless,
lisp programmers who understand what is going on are exceedingly
careful not to taunt the garbage collector if they want their app to
go fast.
the authors of 98%-99% of all introductory java textbooks have
a lot to answer for. my favorite example of the lot is that
they all teach programmers to use String in the following manner:
String query
= "SELECT foo "
+ "FROM bar "
+ "WHERE baz = 'bletch';"
return query;
nowhere do these books ever mention StringBuffer. now java
programmers who have developed a sufficient clue set know that
String is hopelessly inefficient and will instead write the much
preferable:
StringBuffer query = new StringBuffer();
query.append( "SELECT foo ");
query.append( "FROM bar ");
query.append( "WHERE baz = 'bletch';"
return new String( query);
which not only is much more efficient, but Does Not
Taunt The Garbage Collector.
i kind of like _Practical Java_ (Peter Haggar, Addison Wesley)
for its coverage of these details, as well as _Bitter Java_
(Bruce Tate, Manning) for its discussion of how naive programmers
writing Java web apps can (and often do) go seriously wrong
(it talks a lot about efficient use of database backends, providing
relevance to PostgreSQL and this mailing list.)
richard
--
Richard Welty rwelty@averillpark.net
Averill Park Networking 518-573-7592
Java, PHP, PostgreSQL, Unix, Linux, IP Network Engineering, Security
Oops! rwelty@averillpark.net (Richard Welty) was seen spray-painting on a wall:
> "Does Not Taunt The Garbage Collector."
That is the nicest way I have ever seen of characterizing abuses of
system features.
In Java, GC is something people are prone to "Taunt."
In C, there's _something_ surrounding malloc() that often gets
"taunted;" I'm not certain how to characterize it.
In Lisp, the _other_ two things that get "taunted" by bad programmers
are:
a) Recursion (when they think that's the _only_ way to go) and
b) Doing _way_ too much list manipulation using c[ad]+r.
In Forth, the "taunting" of the system tends to come if your code does
more stack manipulation than "real work."
There's a tendancy for these misuses to lead to code being less
readable, to boot...
--
output = ("cbbrowne" "@" "cbbrowne.com")
http://www.ntlug.org/~cbbrowne/linuxxian.html
"Feel free to contact me (flames about my english and the useless of
this driver will be redirected to /dev/null, oh no, it's full...)"
-- Michael Beck, describing the PC-speaker sound device
On Sat, 14 Aug 2004 15:47:41 -0400 Christopher Browne <cbbrowne@acm.org> wrote:
> Oops! rwelty@averillpark.net (Richard Welty) was seen spray-painting on a wall:
> > "Does Not Taunt The Garbage Collector."
> That is the nicest way I have ever seen of characterizing abuses of
> system features.
i was just wondering how many people would remember "Do Not
Taunt Happy Fun Ball".
> In Java, GC is something people are prone to "Taunt."
yes, intentionally or otherwise.
> In C, there's something surrounding malloc() that often gets
> "taunted;" I'm not certain how to characterize it.
> In Lisp, the other two things that get "taunted" by bad programmers
> are:
> a) Recursion (when they think that's the only way to go) and
> b) Doing way too much list manipulation using c[ad]+r.
as a rule of thumb, in GC situations, if you have a choice between
creating one large object or numerous small ones, one large object
will be more efficiently collected and reused. this is why in lisp,
rather than consing up a list, if you can reasonably use an array,
that's what you should do. the principle applies in general to any
programming environment.
> There's a tendancy for these misuses to lead to code being less
> readable, to boot...
there is a wacky subculture in programming of folks who think
that obscure code is somehow "better".
richard
--
Richard Welty rwelty@averillpark.net
Averill Park Networking 518-573-7592
Java, PHP, PostgreSQL, Unix, Linux, IP Network Engineering, Security
Christopher Browne wrote: > Oops! rwelty@averillpark.net (Richard Welty) was seen spray-painting on a wall: > >>"Does Not Taunt The Garbage Collector." > > > That is the nicest way I have ever seen of characterizing abuses of > system features. > > In Java, GC is something people are prone to "Taunt." > > In C, there's _something_ surrounding malloc() that often gets > "taunted;" I'm not certain how to characterize it. > > In Lisp, the _other_ two things that get "taunted" by bad programmers > are: > a) Recursion (when they think that's the _only_ way to go) and > b) Doing _way_ too much list manipulation using c[ad]+r. > > In Forth, the "taunting" of the system tends to come if your code does > more stack manipulation than "real work." > > There's a tendancy for these misuses to lead to code being less > readable, to boot... Just to be an irritant, I'd argue that, at least w.r.t. GC, these are problems for the implementors. I'm not saying it isn't smart to work around language implementation defects, just as it has been recommended to people to use ORDER BY LIMIT 1 and, until recently, EXISTS instead of IN. However, the fundamental problem lies with the implementors, not with the programmer who should be thinking in terms of correctness, not visualizing the machinations of a JVM's GC internals... Mike Mascari
Richard Welty wrote: > nowhere do these books ever mention StringBuffer. now java > programmers who have developed a sufficient clue set know that > String is hopelessly inefficient and will instead write the much > preferable: This is an unfortunate example of an over-simplification that is likely to mislead people greatly. For a more or less complete discussion of this topic (demonstrating that the "dumb book" code is actually better than Richard's alternative) see Jon Skeet's article at http://www.yoda.arachsys.com/java/strings.html. > i kind of like _Practical Java_ (Peter Haggar, Addison Wesley) > for its coverage of these details, Peter Haggar's book is a fair one, and one I'd cautiously consider if Joshua Bloch hadn't written his much better book; but Haggar makes it a little too easy to misunderstand if you don't read closely. I'm looking at Peter's book now. In Praxis 31 where this issue is discussed, Peter Haggar writes some very poor code using the String concatenation operator in order to make it slower in a case where it really isn't substantially different at all. He doesn't mention that the inefficiency of his code arises from things unrelated to string concatenation. He doesn't mention that if he'd written more obvious code it would be faster than anything he could write with StringBuffer. I'd far rather he provided an honest example that demonstrates the real problem, as Jon does in the article above. In many other places as well, Peter's sections often give very bad advice, or only make sense when qualified by the comments in the text, making it very dangerous to browse advice from the table of comments. For example, see Praxis 7, 10, 19, 22, 25, 29, 30, 40, 44, and 45. The book also is riddled throughout with the false premise that one can evaluate the efficiency of code by looking at generated bytecode. Basically, I'd recommend great caution in reading it, and independent confirmation of anything that seems surprising. Or just get Josh Bloch's book instead, which covers the same ground and is far more trustworthy. Anyway, yes you can do Java poorly, but it's become fashionable to say so lately and a lot of people are sure they know exactly how this poor code is written and are willing to tell you so without actually knowing a thing. So just be careful about that. -- www.designacourse.com The Easiest Way to Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation
i've changed the subject as the relevance of this discussion to
8.0 seems a mite difficult to prove...
On Sat, 14 Aug 2004 18:04:52 -0400 Mike Mascari <mascarm@mascari.com> wrote:
> Just to be an irritant, I'd argue that, at least w.r.t. GC, these
> are problems for the implementors. I'm not saying it isn't smart to
> work around language implementation defects, just as it has been
> recommended to people to use ORDER BY LIMIT 1 and, until recently,
> EXISTS instead of IN. However, the fundamental problem lies with the
> implementors, not with the programmer who should be thinking in
> terms of correctness, not visualizing the machinations of a JVM's GC
> internals...
easy to say. not a real practical point of view in practice, except maybe
for some more theoretically minded professorial types.
to take an example from the land of databases, i'm 1 month into a 6 month
contract writing java applications with an informix backend. the databases
are quite a bit larger than i've worked with in the past, so i'm learning quite
a bit about how to write queries and select indices.
it turns out that informix has the same exists vs. in issues that we all know
and love from prior versions of PostgreSQL, which a friend of mine who is
a first rate informix dba advised me of after i was pretty disappointed in the
behavior of my first attempts at a particular set of queries. in fact, the difference
is on the order of a factor of 6 to 8. now this is a query that needs to be
done interactively. i can sit there saying that it's the implementors problem,
or i can write code that returns results in 10 seconds instead of a minute.
i believe that if i asserted that the developers of informix were at fault, and
therefore it wasn't my problem, that it would be very likely that i might not
even make the full 6 months. as little things like eating and paying the
mortgage are important to me, i changed my INs/NOT INs to EXISTS/NOT
EXISTS.
richard
--
Richard Welty rwelty@averillpark.net
Averill Park Networking 518-573-7592
Java, PHP, PostgreSQL, Unix, Linux, IP Network Engineering, Security
Richard,
Actually, I think you will find that current implementations of java
will actually take
String foo = "Hello " + "World" and rewrite it into
String foo = new StringBuffer("Hello").append("World").toString()
But your point is still valid.
Dave
On Sat, 2004-08-14 at 14:27, Richard Welty wrote:
> On Sat, 14 Aug 2004 12:03:21 -0400 Jan Wieck <JanWieck@Yahoo.com> wrote:
>
> > On 8/12/2004 8:53 PM, Richard Welty wrote:
>
> > > On Thu, 12 Aug 2004 14:36:13 -0400 Vivek Khera <khera@kcilink.com> wrote:
> > >> >>>>> "RW" == Richard Welty <rwelty@averillpark.net> writes:
> > >> RW> i'm quite experienced in C and Java, so it's going to be in one of
> > >> RW> those two. any comments from anyone on the language choice?
> > >
> > >> eRServer is written in Java. It sucks up about 200Mb+ virtual memory
> > >> for a teeny-tiny little database. I'd avoid java :-)
> > >
> > > java often sucks up too much memory. java doesn't have to suck
> > > up too much memory, it just usually gets written that way.
>
> > Right. The garbage collection automatically taking care of unreferenced
> > objects as a stop-gap for resource leakage is abused by lazy programmers
> > as a general purpose cleanup mechanism.
>
> some of it is this, certainly. some of it is bad education.
>
> i was a professional lisp programmer for some 10+ years. lisp, of
> course, has the ancestral garbage collection scheme, and the
> lisp garbage collectors at this juncture are very, very, very good,
> much more mature than java's garbage collector. nonetheless,
> lisp programmers who understand what is going on are exceedingly
> careful not to taunt the garbage collector if they want their app to
> go fast.
>
> the authors of 98%-99% of all introductory java textbooks have
> a lot to answer for. my favorite example of the lot is that
> they all teach programmers to use String in the following manner:
>
> String query
> = "SELECT foo "
> + "FROM bar "
> + "WHERE baz = 'bletch';"
>
> return query;
>
> nowhere do these books ever mention StringBuffer. now java
> programmers who have developed a sufficient clue set know that
> String is hopelessly inefficient and will instead write the much
> preferable:
>
> StringBuffer query = new StringBuffer();
>
> query.append( "SELECT foo ");
> query.append( "FROM bar ");
> query.append( "WHERE baz = 'bletch';"
>
> return new String( query);
>
> which not only is much more efficient, but Does Not
> Taunt The Garbage Collector.
>
> i kind of like _Practical Java_ (Peter Haggar, Addison Wesley)
> for its coverage of these details, as well as _Bitter Java_
> (Bruce Tate, Manning) for its discussion of how naive programmers
> writing Java web apps can (and often do) go seriously wrong
> (it talks a lot about efficient use of database backends, providing
> relevance to PostgreSQL and this mailing list.)
>
> richard
--
Dave Cramer
519 939 0336
ICQ # 14675561
On Sat, 14 Aug 2004, Richard Welty wrote: > the authors of 98%-99% of all introductory java textbooks have > a lot to answer for. my favorite example of the lot is that > they all teach programmers to use String in the following manner: > > String query > = "SELECT foo " > + "FROM bar " > + "WHERE baz = 'bletch';" > There is actually nothing wrong with this particular example. I realize you are pointing out an issue that can happen, so this is a just "for the record" post. In this case the concatenation is done at compile time. See: http://www.java-performance-portal.org/article6.html Further the usage of string concatenation is easier to read/write so you need to actually consider wether the code in question is actually a hotspot and worth StringBuffer(ifying). Again your example is pointing to a database query in which case so many other things are going on it's unlikely to make any performance difference. Kris Jurka
Richard Welty <rwelty@averillpark.net> writes:
> String query
> = "SELECT foo "
> + "FROM bar "
> + "WHERE baz = 'bletch';"
This particular expression is rewritten by the compiler to use
StringBuffer, so is equivalent to:
> StringBuffer query = new StringBuffer();
>
> query.append( "SELECT foo ");
> query.append( "FROM bar ");
> query.append( "WHERE baz = 'bletch';"
>
> return new String( query);
Maybe you are thinking in something like
String foo = ""
while(cond) {
foo += bar;
}
which is, indeed, quite inefficient.
Regards,
Manuel.
Dave Cramer wrote:
> Richard,
>
> Actually, I think you will find that current implementations of java
> will actually take
>
> String foo = "Hello " + "World" and rewrite it into
>
> String foo = new StringBuffer("Hello").append("World").toString()
>
> But your point is still valid.
>
Oh c'mon. Give the current Java compilers some more credit.
Most Java compilers, will optimize string concatenation whenever
possible. The examples given here falls into the category of simple
constant evaluation. The above example will be optimizied into:
String foo = "Hello World".
The same is true for Richards example.
Try it yourself. Compile a simple program "Hello " + "World" in it, then
use jad to decompile, or if you don't have it available, use strings(1)
on the resulting class file.
Regards,
Thomas Hallgren
Thomas,
It was a simple example. My point was that no modern java compiler will
actually concatenate strings by instantiating and copying. They will
either do as Thomas suggests, or in more complex examples use .append()
Dave
On Mon, 2004-08-16 at 10:13, Thomas Hallgren wrote:
> Dave Cramer wrote:
>
> > Richard,
> >
> > Actually, I think you will find that current implementations of java
> > will actually take
> >
> > String foo = "Hello " + "World" and rewrite it into
> >
> > String foo = new StringBuffer("Hello").append("World").toString()
> >
> > But your point is still valid.
> >
> Oh c'mon. Give the current Java compilers some more credit.
>
> Most Java compilers, will optimize string concatenation whenever
> possible. The examples given here falls into the category of simple
> constant evaluation. The above example will be optimizied into:
>
> String foo = "Hello World".
>
> The same is true for Richards example.
>
> Try it yourself. Compile a simple program "Hello " + "World" in it, then
> use jad to decompile, or if you don't have it available, use strings(1)
> on the resulting class file.
>
> Regards,
>
> Thomas Hallgren
>
>
--
Dave Cramer
519 939 0336
ICQ # 14675561
On Mon, 16 Aug 2004 10:27:04 -0400 Dave Cramer <pg@fastcrypt.com> wrote:
> It was a simple example. My point was that no modern java compiler will
> actually concatenate strings by instantiating and copying. They will
> either do as Thomas suggests, or in more complex examples use .append()
i was trying to drop out of the discussion as it's way off topic, but i must
confess that i've spent the time since last weekend actually learning
more about the issues. i'll put together something on the subject
and probably post a web page for comment. as it happens, there are
elements of truth to both sides of this, and it pays to actually look at
the things you are likely to want to do and think about the best way
to do them rather than just do something in a knee jerk manner.
yes, the example in Haggar is a bit contrived, and my example was
poorly chosen. the stuff i'm about to write up is quite different, and
much more carefully thought out.
richard
--
Richard Welty rwelty@averillpark.net
Averill Park Networking 518-573-7592
Java, PHP, PostgreSQL, Unix, Linux, IP Network Engineering, Security