Thread: 7.5 release notes
I have completed the 7.5 release notes. You can view them in HTML on the developer web page. I have marked a few items with question marks that need to be addressed. I am looking for improvements, even minor ones. Either send in a patch or committers can modify the file directly. Of course this file will be updated regularly all the way up to final release to it isn't in its final form. We don't have a /HISTORY file anymore so you have to view it via HTML. /HISTORY will be in the final tarball, however. Do people want a big-picture paragraph at the top talking about the release? Some releases get them, some don't, but this one could if folks want it. FYI, I have a NYC meeting on Monday so I am not going to OSCON until Tuesday so I will be around regularly for 2-3 more days. One thing we now need to look at is missing documentation. The release notes usually make missing documentation very glaring and I think we need to work up a list of what is missing. There isn't that much missing except for the features we just finalized and stuff put in during the past month of push to beta. I am thinking of marking the items needing docs right in the release notes with [DOCS] and that way everyone can see what is needed. -- 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 Sat, 2004-07-24 at 21:25, Bruce Momjian wrote:
> I have completed the 7.5 release notes. You can view them in HTML on
> the developer web page. I have marked a few items with question marks
> that need to be addressed. I am looking for improvements, even minor
> ones. Either send in a patch or committers can modify the file
> directly.
I don't understand the following passage:
"When matching GROUP BY names, prefer local FROM columns first, then
SELECT aliases, and then outer FROM columns (Tom)
This change was made because it is considered more consistent than the
previous behavior."
Perhaps it could be more clear? I don't know where else I'd go to find
more thorough documentation on that subject.
Also, I've included a couple typo fixes below.
Regards,
Jeff Davis
--- release.html.old 2004-07-25 03:06:28.000000000 -0700
+++ release.html 2004-07-25 03:10:21.000000000 -0700
@@ -99,7 +99,6 @@
</p><p> Before this change some queries would not use an
index if the data
types did not exactly match. This improvement makes index usage
more
intuitive and consistent.
- match exactly
</p></li><li><p> New buffer replacement strategy that
improves caching (Jan)
</p><p> Prior releases use a least-recently-used (LRU) cache
to keep
recently referenced pages in the cache. Unfortunately, the cache
@@ -129,7 +128,7 @@
resulting in improved performance. The close relationship between
our developers and users reporting problems allows us to make
rapid and complex optimizer improvements that would be very
- difficult for lose-source companies to emulate.
+ difficult for closed-source companies to emulate.
</p></li><li><p> Improve btree index performance for
duplicate keys (Dmitry Tkach, Tom)
</p><p> This improves the way indexes are scanned when many
duplicate values exist in the index.
On Sun, Jul 25, 2004 at 00:25:43 -0400, Bruce Momjian <pgman@candle.pha.pa.us> wrote: > I have completed the 7.5 release notes. You can view them in HTML on > the developer web page. I have marked a few items with question marks > that need to be addressed. I am looking for improvements, even minor > ones. Either send in a patch or committers can modify the file > directly. There is a typo (transaction is misspelled) in the following line: Prior release had no such capability; there was no way to recover from a statement failure in a transation. This "match exactly" at the end of the following appears to be spurious: Before this change some queries would not use an index if the data types did not exactly match. This improvement makes indexusage more intuitive and consistent. match exactly In the following paragraph there appear to be two typos. I think "optimizer make" should be "optimizer makes" and that "lose-source" should be "closed-source". It is difficult to explain all the optimizer improvements that go into a release like this. They involve complex adjustmentsto the logic used to select indexes, join methods, and join order. They are difficult to explain, but the resultis that the optimizer make quicker and better choices in how to execute queries, resulting in improved performance.The close relationship between our developers and users reporting problems allows us to make rapid and complexoptimizer improvements that would be very difficult for lose-source companies to emulate.
Jeff Davis <jdavis-pgsql@empires.org> writes:
> I don't understand the following passage:
> "When matching GROUP BY names, prefer local FROM columns first, then
> SELECT aliases, and then outer FROM columns (Tom)
> This change was made because it is considered more consistent than the
> previous behavior."
That shouldn't be there at all, since the change was made and documented
in 7.4.3. We don't normally duplicate previous release notes, do we?
regards, tom lane
Bruno Wolff III <bruno@wolff.to> writes:
> In the following paragraph there appear to be two typos. I think
> "optimizer make" should be "optimizer makes" and that "lose-source"
> should be "closed-source".
> It is difficult to explain all the optimizer improvements that go into a release like this. They involve complex
adjustmentsto the logic used to select indexes, join methods, and join order. They are difficult to explain, but the
resultis that the optimizer make quicker and better choices in how to execute queries, resulting in improved
performance.The close relationship between our developers and users reporting problems allows us to make rapid and
complexoptimizer improvements that would be very difficult for lose-source companies to emulate.
I'd suggest removing the paragraph entirely, on the grounds that it is
content-free fluff.
regards, tom lane
Bruce Momjian wrote: > I have completed the 7.5 release notes. You can view them in HTML on > the developer web page. I have marked a few items with question marks > that need to be addressed. I am looking for improvements, even minor > ones. Either send in a patch or committers can modify the file > directly. In E.1.1 Overview: "... This release supports Windows NT 4 and all later releases. It does not support earlier releases like Windows 95, 98, or ME because ... " Win98 and WinME is released _after_ NT4. See http://www.computerhope.com/history/windows.htm Perhaps it's better to say: "We only support NT-based Windows such as NT4, Win2k/XP/2003/later. Old 9x-based Windows versions such as Win95/98/Me are not supported because ..." Btw, can 7.5 run on WinCE/XP Media Center/XP SP2/etc? -- dave
On Sun, 2004-07-25 at 05:25, Bruce Momjian wrote: > I have completed the 7.5 release notes. You can view them in HTML on > the developer web page. I have marked a few items with question marks > that need to be addressed. I am looking for improvements, even minor > ones. Either send in a patch or committers can modify the file > directly. > Looks good. These take time and effort, much appreciated. Forward-looking phrases ======================= Overall, I'd ask that we don't refer back to what earlier releases didn't do, or whatever limitations they were thought to have. If a release has "new feature X", everybody can work out it wasn't there in the last release. The phrasing is delicate so you describe the new thing without running down the old. e.g. (1) Previous releases required the Unix emulation toolkit Cygwin for Win32 support. to The server no longer relies upon Cygwin for Unix emulation under win32. e.g. (2) Prior release had no such capability; there was no way to recover from a statement failure in a transaction. to Should a statement fail inside a transaction, there is now a way to handle this error and continue processing. (Of course, somebody will let me know about my Brit-style passive voice, I'm sure...) Migration ========= These release notes refer to "GUC"s, whereas the previous release notes and the manual refers to "server configuration parameters". I understand the former, but prefer the latter description for these user-focused notes. Also, it might be worth mentioning that pg_dump itself has also been substantially improved, and now provides an improved upgrade path for existing users. Here's my attempt at a short paragraph for PITR... Point-In-Time Recovery enhances Data Resilience PostgreSQL can now recover from total disk failure using backups and transaction log archives. Recovery can be controlled to stop at a specified point in time or at some transaction in the past. Transaction log archiving is automated and calls a user-supplied external program to allow integration with external backup devices and related software. > Do people want a big-picture paragraph at the top talking about the > release? Some releases get them, some don't, but this one could if > folks want it. > Yes, thats a good idea. Best Regards, Simon Riggs
Bruce Momjian said: > I have completed the 7.5 release notes. You can view them in HTML on > the developer web page. I have marked a few items with question marks > that need to be addressed. I am looking for improvements, even minor > ones. Either send in a patch or committers can modify the file > directly. > I presume we can also just make some comments ;-) this item: Add new GUC parameter to report useful information at the start of each log line should probably read "Add new GUC parameter log_line_prefix ....." I think this item belongs to me, or me and Tom: Replace the virtual_host and tcpip_socket parameters with a unified listen_addresses parameter. Conversely, Tom deserves joint billing for dollar quoting, as most of what I did was based on his work. David Fetter should be mentioned under the dollar quoting and plperl items, as he did documentation for both. Tom's implementation of a new flex-based lexer for psql is a significant source code change which should be mentioned. cheers andrew
Simon Riggs wrote: > On Sun, 2004-07-25 at 05:25, Bruce Momjian wrote: > > I have completed the 7.5 release notes. You can view them in HTML on > > the developer web page. I have marked a few items with question marks > > that need to be addressed. I am looking for improvements, even minor > > ones. Either send in a patch or committers can modify the file > > directly. > > > > Looks good. These take time and effort, much appreciated. > > Forward-looking phrases > ======================= > > Overall, I'd ask that we don't refer back to what earlier releases > didn't do, or whatever limitations they were thought to have. > > If a release has "new feature X", everybody can work out it wasn't there > in the last release. The phrasing is delicate so you describe the new > thing without running down the old. > > e.g. (1) > > Previous releases required the Unix emulation toolkit Cygwin for Win32 > support. > > to > > The server no longer relies upon Cygwin for Unix emulation under win32. > > e.g. (2) > > Prior release had no such capability; there was no way to recover from a > statement failure in a transaction. > > to > > Should a statement fail inside a transaction, there is now a way to > handle this error and continue processing. > > (Of course, somebody will let me know about my Brit-style passive voice, > I'm sure...) I understand your reason for making these changes. However, I am unsure if your new wording is as clear as the previous one. Our reliance on Cygwin and inability to prevent an error from aborting a transaction were limitation and it seems clearer to just state that we have fixed them rather than try to sugar-code our previous limitations. Marketing-wise, I think you are right, but from an honesty/clarity perspective, I think the current wording is better. What I could do is remove some of the later references where we were talking updating the system catalog to do various things. I am not sure it is needed. Comments? > > Migration > ========= > These release notes refer to "GUC"s, whereas the previous release notes > and the manual refers to "server configuration parameters". I understand > the former, but prefer the latter description for these user-focused > notes. Updated. > Also, it might be worth mentioning that pg_dump itself has also been > substantially improved, and now provides an improved upgrade path for > existing users. It is mentioned as the top item in the pg_dump section. It doesn't seem like a migration issue to me though. Is it a major feature? > Here's my attempt at a short paragraph for PITR... > > Point-In-Time Recovery enhances Data Resilience > > PostgreSQL can now recover from total disk failure using backups and > transaction log archives. Recovery can be controlled to stop at a > specified point in time or at some transaction in the past. Transaction > log archiving is automated and calls a user-supplied external program to > allow integration with external backup devices and related software. We can improve the wording, but if the motivation is to reduced saying bad things about our previous functionality, let me explain my perspective. Basically, my goal with these release notes is to make it as clear as possible why this new feature would be valuable to the reader. If it makes our previous release look bad, so be it. For me, clarity and candor gain a lot more credibility than trying to cover over missing functionality in the past. I am not saying we have to be so honest that we bash PostgreSQL, but in cases where we adjust wording to try to prevent ourselves from looking bad, it is best to be honest and clear about our limitations. I think in the long run it gains us lots of credibility (and ultimately volunteers). > > > Do people want a big-picture paragraph at the top talking about the > > release? Some releases get them, some don't, but this one could if > > folks want it. > > > > Yes, thats a good idea. OK. -- 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
Tom Lane wrote: > Jeff Davis <jdavis-pgsql@empires.org> writes: > > I don't understand the following passage: > > > "When matching GROUP BY names, prefer local FROM columns first, then > > SELECT aliases, and then outer FROM columns (Tom) > > This change was made because it is considered more consistent than the > > previous behavior." > > That shouldn't be there at all, since the change was made and documented > in 7.4.3. We don't normally duplicate previous release notes, do we? Agreed. Removed. -- 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
Jeff Davis wrote: > On Sat, 2004-07-24 at 21:25, Bruce Momjian wrote: > > I have completed the 7.5 release notes. You can view them in HTML on > > the developer web page. I have marked a few items with question marks > > that need to be addressed. I am looking for improvements, even minor > > ones. Either send in a patch or committers can modify the file > > directly. > > I don't understand the following passage: > > "When matching GROUP BY names, prefer local FROM columns first, then > SELECT aliases, and then outer FROM columns (Tom) > > This change was made because it is considered more consistent than the > previous behavior." > > Perhaps it could be more clear? I don't know where else I'd go to find > more thorough documentation on that subject. Item removed. Tom said it was already in 7.4.3. I made the adjustments below. --------------------------------------------------------------------------- > > Also, I've included a couple typo fixes below. > > Regards, > Jeff Davis > > --- release.html.old 2004-07-25 03:06:28.000000000 -0700 > +++ release.html 2004-07-25 03:10:21.000000000 -0700 > @@ -99,7 +99,6 @@ > </p><p> Before this change some queries would not use an > index if the data > types did not exactly match. This improvement makes index usage > more > intuitive and consistent. > - match exactly > </p></li><li><p> New buffer replacement strategy that > improves caching (Jan) > </p><p> Prior releases use a least-recently-used (LRU) cache > to keep > recently referenced pages in the cache. Unfortunately, the cache > @@ -129,7 +128,7 @@ > resulting in improved performance. The close relationship between > our developers and users reporting problems allows us to make > rapid and complex optimizer improvements that would be very > - difficult for lose-source companies to emulate. > + difficult for closed-source companies to emulate. > </p></li><li><p> Improve btree index performance for > duplicate keys (Dmitry Tkach, Tom) > </p><p> This improves the way indexes are scanned when many > duplicate values exist in the index. > > > -- 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
Bruno Wolff III wrote: > On Sun, Jul 25, 2004 at 00:25:43 -0400, > Bruce Momjian <pgman@candle.pha.pa.us> wrote: > > I have completed the 7.5 release notes. You can view them in HTML on > > the developer web page. I have marked a few items with question marks > > that need to be addressed. I am looking for improvements, even minor > > ones. Either send in a patch or committers can modify the file > > directly. > > There is a typo (transaction is misspelled) in the following line: > Prior release had no such capability; there was no way to recover from a statement failure in a transation. This > > "match exactly" at the end of the following appears to be spurious: Yes, removed. > Before this change some queries would not use an index if the data types did not exactly match. This improvement makesindex usage more intuitive and consistent. match exactly > > In the following paragraph there appear to be two typos. I think > "optimizer make" should be "optimizer makes" and that "lose-source" > should be "closed-source". > It is difficult to explain all the optimizer improvements that go into a release like this. They involve complex adjustmentsto the logic used to select indexes, join methods, and join order. They are difficult to explain, but the resultis that the optimizer make quicker and better choices in how to execute queries, resulting in improved performance.The close relationship between our developers and users reporting problems allows us to make rapid and complexoptimizer improvements that would be very difficult for lose-source companies to emulate. Fixed.> -- 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
All added. Thanks. --------------------------------------------------------------------------- Andrew Dunstan wrote: > Bruce Momjian said: > > I have completed the 7.5 release notes. You can view them in HTML on > > the developer web page. I have marked a few items with question marks > > that need to be addressed. I am looking for improvements, even minor > > ones. Either send in a patch or committers can modify the file > > directly. > > > > I presume we can also just make some comments ;-) > > this item: > > Add new GUC parameter to report useful information at the start of each > log line > should probably read "Add new GUC parameter log_line_prefix ....." > > I think this item belongs to me, or me and Tom: > > Replace the virtual_host and tcpip_socket parameters with a unified > listen_addresses parameter. > > Conversely, Tom deserves joint billing for dollar quoting, as most of what I > did was based on his work. > > David Fetter should be mentioned under the dollar quoting and plperl items, > as he did documentation for both. > > Tom's implementation of a new flex-based lexer for psql is a significant > source code change which should be mentioned. > > cheers > > andrew > > > > > -- 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
Adjustment made:
http://pgfoundry.org/projects/pginstaller</ulink>. This release
supports NT-based Windows releases like NT4, Win2k, XP, Win2003.
Older releases like Windows 95, 98, and ME are not supported because
these operating systems do not have the infrastructure to
support PostgreSQL.
---------------------------------------------------------------------------
David Garamond wrote:
> Bruce Momjian wrote:
> > I have completed the 7.5 release notes. You can view them in HTML on
> > the developer web page. I have marked a few items with question marks
> > that need to be addressed. I am looking for improvements, even minor
> > ones. Either send in a patch or committers can modify the file
> > directly.
>
> In E.1.1 Overview: "... This release supports Windows NT 4 and all later
> releases. It does not support earlier releases like Windows 95, 98, or
> ME because ... "
>
> Win98 and WinME is released _after_ NT4. See
>
> http://www.computerhope.com/history/windows.htm
>
> Perhaps it's better to say: "We only support NT-based Windows such as
> NT4, Win2k/XP/2003/later. Old 9x-based Windows versions such as
> Win95/98/Me are not supported because ..."
>
> Btw, can 7.5 run on WinCE/XP Media Center/XP SP2/etc?
>
> --
> dave
>
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend
>
--
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
\Tom Lane wrote: > Bruno Wolff III <bruno@wolff.to> writes: > > In the following paragraph there appear to be two typos. I think > > "optimizer make" should be "optimizer makes" and that "lose-source" > > should be "closed-source". > > > It is difficult to explain all the optimizer improvements that go into a release like this. They involve complex adjustmentsto the logic used to select indexes, join methods, and join order. They are difficult to explain, but the resultis that the optimizer make quicker and better choices in how to execute queries, resulting in improved performance.The close relationship between our developers and users reporting problems allows us to make rapid and complexoptimizer improvements that would be very difficult for lose-source companies to emulate. > > I'd suggest removing the paragraph entirely, on the grounds that it is > content-free fluff. Hey, that's your content-free fluff. :-) You make major optimizer improvements in every release, but they are so complex it is impossible to explain them to people. This paragraph tries to address that. However, since you don't like it, I will remove it entirely. If you change your mind we can re-add it. -- 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
All fixed. Thanks. --------------------------------------------------------------------------- Bruno Wolff III wrote: > On Sun, Jul 25, 2004 at 00:25:43 -0400, > Bruce Momjian <pgman@candle.pha.pa.us> wrote: > > I have completed the 7.5 release notes. You can view them in HTML on > > the developer web page. I have marked a few items with question marks > > that need to be addressed. I am looking for improvements, even minor > > ones. Either send in a patch or committers can modify the file > > directly. > > There is a typo (transaction is misspelled) in the following line: > Prior release had no such capability; there was no way to recover from a statement failure in a transation. This > > "match exactly" at the end of the following appears to be spurious: > > Before this change some queries would not use an index if the data types did not exactly match. This improvement makesindex usage more intuitive and consistent. match exactly > > In the following paragraph there appear to be two typos. I think > "optimizer make" should be "optimizer makes" and that "lose-source" > should be "closed-source". > It is difficult to explain all the optimizer improvements that go into a release like this. They involve complex adjustmentsto the logic used to select indexes, join methods, and join order. They are difficult to explain, but the resultis that the optimizer make quicker and better choices in how to execute queries, resulting in improved performance.The close relationship between our developers and users reporting problems allows us to make rapid and complexoptimizer improvements that would be very difficult for lose-source companies to emulate. > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@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
On Mon, 2004-07-26 at 00:55, Bruce Momjian wrote: > Simon Riggs wrote: > > On Sun, 2004-07-25 at 05:25, Bruce Momjian wrote: > > > I have completed the 7.5 release notes. You can view them in HTML on > > > the developer web page. I have marked a few items with question marks > > > that need to be addressed. I am looking for improvements, even minor > > > ones. Either send in a patch or committers can modify the file > > > directly. > > > > > > > Those were just examples of a suggested style change for some items. > Basically, my goal with these release notes is to make it as clear as > possible why this new feature would be valuable to the reader. Completely Agree. > If it makes our previous release look bad, so be it. Oh. > For me, clarity and > candor gain a lot more credibility than trying to cover over missing > functionality in the past. I am not saying we have to be so honest that > we bash PostgreSQL, but in cases where we adjust wording to try to > prevent ourselves from looking bad, it is best to be honest and clear > about our limitations. I think in the long run it gains us lots of > credibility (and ultimately volunteers). > I see this as merely a half-full/half-empty viewpoint issue. Honesty and clarity are wonderful things and I subscribe to them. Using them only to describe your own viewpoint is not a reasonable point to make in a hopefully rational discussion about writing style... I'll go back to my docs now, but I guess we may relive this again when you see some of the honest, clear and positive changes I am suggesting. :) -- Best Regards, Simon Riggs
Simon Riggs wrote: > > For me, clarity and > > candor gain a lot more credibility than trying to cover over missing > > functionality in the past. I am not saying we have to be so honest that > > we bash PostgreSQL, but in cases where we adjust wording to try to > > prevent ourselves from looking bad, it is best to be honest and clear > > about our limitations. I think in the long run it gains us lots of > > credibility (and ultimately volunteers). > > > > I see this as merely a half-full/half-empty viewpoint issue. > > Honesty and clarity are wonderful things and I subscribe to them. Using > them only to describe your own viewpoint is not a reasonable point to > make in a hopefully rational discussion about writing style... > > I'll go back to my docs now, but I guess we may relive this again when > you see some of the honest, clear and positive changes I am suggesting. > :) I wasn't suggesting yours were dishonest. I was saying that I was aiming for the clearest style whether is makes PostgreSQL look good or not. I figured saying "in the past you had to do X" was clearer than saying "you don't have to do X anymore". I am, of course, am open to the community's feedback on this. -- 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