Re: Release notes

I have completed my first pass over the release notes and Tom has made
some additions:

http://momjian.postgresql.org/cgi-bin/pgrelease

I will probably go over them again in a few hours, update them to
current CVS, then move them into our SGML documentation by Monday.

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

On 9/15/06, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> I have completed my first pass over the release notes and Tom has made
> some additions:
>
> http://momjian.postgresql.org/cgi-bin/pgrelease

In Server changes, the two first lines are:

# Improve performance of statistics monitoring, especially
pg_stat_activity (Tom)
# Improve performance of statistics monitoring (Tom)

This is probably an error.

--
Guillaume

Fixed.

---------------------------------------------------------------------------

Guillaume Smet wrote:
> On 9/15/06, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > I have completed my first pass over the release notes and Tom has made
> > some additions:
> >
> > http://momjian.postgresql.org/cgi-bin/pgrelease
>
> In Server changes, the two first lines are:
>
> # Improve performance of statistics monitoring, especially
> pg_stat_activity (Tom)
> # Improve performance of statistics monitoring (Tom)
>
> This is probably an error.
>
> --
> Guillaume
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian wrote:
> I have completed my first pass over the release notes and Tom has made
> some additions:
>
> http://momjian.postgresql.org/cgi-bin/pgrelease
>
> I will probably go over them again in a few hours, update them to
> current CVS, then move them into our SGML documentation by Monday.

Oh, another typo:

This changes the previous behavior where concatenation would adjust the
lower array dimmensions.

It's "dimensions", single m.

Further below, it says:

For example, '2006-05-24 21:11 Americas/New_York'::timestamptz.

However, the example is invalid. The correct example should be

For example, '2006-05-24 21:11 America/New_York'::timestamptz.

Note these two entries:

Add index information to /contrib/pgstattuple (ITAGAKI Takahiro)

Add functions to /contrib/pgstattuple that show index statistics and
index page contents (Satoshi Nagayasu)

They should probably be merged into one.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > I have completed my first pass over the release notes and Tom has made
> > some additions:
> >
> > http://momjian.postgresql.org/cgi-bin/pgrelease
> >
> > I will probably go over them again in a few hours, update them to
> > current CVS, then move them into our SGML documentation by Monday.
>
> Oh, another typo:
>
> This changes the previous behavior where concatenation would adjust the
> lower array dimmensions.
>
> It's "dimensions", single m.

OK, fixed. I ran spellcheck again and didn't find anything new.
>
> Further below, it says:
>
> For example, '2006-05-24 21:11 Americas/New_York'::timestamptz.
>
> However, the example is invalid. The correct example should be
>
> For example, '2006-05-24 21:11 America/New_York'::timestamptz.

Fixed.

> Note these two entries:
>
> Add index information to /contrib/pgstattuple (ITAGAKI Takahiro)
>
> Add functions to /contrib/pgstattuple that show index statistics and
> index page contents (Satoshi Nagayasu)
>
> They should probably be merged into one.

Done.

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

I see two entries:
* Improve subtransaction performance (Alvaro, Itagaki Takahiro, Tom)
* Improve sub-transaction performance (Itagaki Takahiro)
Aren't they the same?

Markup: New operators for array-subset comparisons (<@, @>, &amp;&amp;)

--
Teodor Sigaev E-mail: teodor(at)sigaev(dot)ru
WWW: http://www.sigaev.ru/

Teodor Sigaev wrote:
> I see two entries:
> * Improve subtransaction performance (Alvaro, Itagaki Takahiro, Tom)
> * Improve sub-transaction performance (Itagaki Takahiro)
> Aren't they the same?

Yes, removed.

> Markup: New operators for array-subset comparisons (<@, @>, &amp;&amp;)

Yes, that will be fixed in the move to SGML today.

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

I couldn't remember if you wanted grammar/spelling nitpicks, so I
included them... sorry for the noise if you didn't want them.

#Improve performance of statistics monitoring, especially
pg_stat_activity (Tom)#

I would s/pg_stat_activity/stats_command_string/, since that's where the
actual change was. Can probably get combined with "Default
stats_command_string to 'on'" as well.

"Add system view pg_prepared_statements to show prepared statements
(Joachim Wieland)
Add system view pg_cursors to show open cursors (Joachim Wieland)

Both this and pg_prepared_statements are very useful for pooled
connection setups."

Should read "Both of these are very useful..."

"The old behavior is still available by omitting '.'. The new behavior is
substantially more useful since it allows, for example, triggers to
check for data changes with 'if row(new.) is distinct from row(old.*)'."

This isn't really clear... are you saying you can do if row(new*)? Also,
is the lack of * in the new example intentional?

"Allow placeholder (shell) types to be create (Martijn van Oosterhout)"

should be created...

"Remove dead index entries during btree page split (Junji Teramoto)"

Technically should be s/during/before/. Though, this is already listed
before under performance; not sure what the intention with duplicate
entries is...

"Avoid extra scan of table during VACUUM of index-less table (Greg
Stark)"

Should be 'tables'.

"Add option to allow indexes to be created indexes without blocking
concurrent writes to the table (Greg Stark)"

Drop second 'indexes'.

"Add option to run the entire session in a single transaction (Simon)"

If this is doing what I think it is, it'd be clearer to say "allow
turning autocommit off". We're not actually inforcing that the entire
session be a single transaction, right?

"Rtree has been re implemented using GIST."

Missing -.
--
Jim Nasby jimn(at)enterprisedb(dot)com
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)

Jim C. Nasby wrote:
> I couldn't remember if you wanted grammar/spelling nitpicks, so I
> included them... sorry for the noise if you didn't want them.
>
> #Improve performance of statistics monitoring, especially
> pg_stat_activity (Tom)#
>
> I would s/pg_stat_activity/stats_command_string/, since that's where the
> actual change was. Can probably get combined with "Default
> stats_command_string to 'on'" as well.
>
> "Add system view pg_prepared_statements to show prepared statements
> (Joachim Wieland)
> Add system view pg_cursors to show open cursors (Joachim Wieland)

Good.

>
> Both this and pg_prepared_statements are very useful for pooled
> connection setups."
>
> Should read "Both of these are very useful..."

I don't think I can't change that because they are two separate bullet
items.

> "The old behavior is still available by omitting '.'. The new behavior is
> substantially more useful since it allows, for example, triggers to
> check for data changes with 'if row(new.) is distinct from row(old.*)'."
>
> This isn't really clear... are you saying you can do if row(new*)? Also,
> is the lack of * in the new example intentional?
>

Yea, it was confusing. Updated:

Yes, it was confusing. I reordered it to be:

The new behavior is substantially more useful since it allows,
for example, triggers to check for data changes with <literal>IF
row(new.*) IS DISTINCT FROM row(old.*)</>. The old behavior is
still available by omitting <literal>.*</>.

I made all the other changes you listed below. If anyone has other
improvements, please let me know.

---------------------------------------------------------------------------

> "Allow placeholder (shell) types to be create (Martijn van Oosterhout)"
>
> should be created...
>
> "Remove dead index entries during btree page split (Junji Teramoto)"
>
> Technically should be s/during/before/. Though, this is already listed
> before under performance; not sure what the intention with duplicate
> entries is...

>
> "Avoid extra scan of table during VACUUM of index-less table (Greg
> Stark)"
>
> Should be 'tables'.
>
> "Add option to allow indexes to be created indexes without blocking
> concurrent writes to the table (Greg Stark)"
>
> Drop second 'indexes'.
>
> "Add option to run the entire session in a single transaction (Simon)"
>
> If this is doing what I think it is, it'd be clearer to say "allow
> turning autocommit off". We're not actually inforcing that the entire
> session be a single transaction, right?
>
> "Rtree has been re implemented using GIST."
>
> Missing -.
> --
> Jim Nasby jimn(at)enterprisedb(dot)com
> EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

On Mon, Sep 18, 2006 at 06:47:02PM -0400, Bruce Momjian wrote:
> > Both this and pg_prepared_statements are very useful for pooled
> > connection setups."
> >
> > Should read "Both of these are very useful..."
>
> I don't think I can't change that because they are two separate bullet
> items.

Except it's refering to both items. Maybe the two items should just be
combined into one?
--
Jim Nasby jimn(at)enterprisedb(dot)com
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)

Jim C. Nasby wrote:
> On Mon, Sep 18, 2006 at 06:47:02PM -0400, Bruce Momjian wrote:
> > > Both this and pg_prepared_statements are very useful for pooled
> > > connection setups."
> > >
> > > Should read "Both of these are very useful..."
> >
> > I don't think I can't change that because they are two separate bullet
> > items.
>
> Except it's refering to both items. Maybe the two items should just be
> combined into one?

Please post some combined wording, but I am afraid it will be too
complicated to merge them.

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

On Tue, Sep 19, 2006 at 09:37:39AM -0400, Bruce Momjian wrote:
> Jim C. Nasby wrote:
> > On Mon, Sep 18, 2006 at 06:47:02PM -0400, Bruce Momjian wrote:
> > > > Both this and pg_prepared_statements are very useful for pooled
> > > > connection setups."
> > > >
> > > > Should read "Both of these are very useful..."
> > >
> > > I don't think I can't change that because they are two separate bullet
> > > items.
> >
> > Except it's refering to both items. Maybe the two items should just be
> > combined into one?
>
> Please post some combined wording, but I am afraid it will be too
> complicated to merge them.

- Add pg_prepared_statements and pg_cursors system views to show prepared
statements and open cursors.

Both of these are very useful for pooled connection setups.
--
Jim Nasby jimn(at)enterprisedb(dot)com
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)

Jim C. Nasby wrote:
> On Tue, Sep 19, 2006 at 09:37:39AM -0400, Bruce Momjian wrote:
> > Jim C. Nasby wrote:
> > > On Mon, Sep 18, 2006 at 06:47:02PM -0400, Bruce Momjian wrote:
> > > > > Both this and pg_prepared_statements are very useful for pooled
> > > > > connection setups."
> > > > >
> > > > > Should read "Both of these are very useful..."
> > > >
> > > > I don't think I can't change that because they are two separate bullet
> > > > items.
> > >
> > > Except it's refering to both items. Maybe the two items should just be
> > > combined into one?
> >
> > Please post some combined wording, but I am afraid it will be too
> > complicated to merge them.
>
> - Add pg_prepared_statements and pg_cursors system views to show prepared
> statements and open cursors.
>
> Both of these are very useful for pooled connection setups.

No, you are confusing two different pieces of functionality, just to get
a single description. It is not worth it.

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

On Fri, 2006-09-15 at 15:37 -0400, Bruce Momjian wrote:
> I have completed my first pass over the release notes and Tom has made
> some additions:
>
> http://momjian.postgresql.org/cgi-bin/pgrelease
>
> I will probably go over them again in a few hours, update them to
> current CVS, then move them into our SGML documentation by Monday.

We talk about "standby point-in-time-recovery (PITR) servers" in the
release notes, but in the docs PITR has now been replaced by Continuous
Archiving and we talk about Warm Standby servers.

Can we call them Warm Standby servers? That makes more sense for the
general reader and matches the docs.

Also, not sure what the thoughts are regarding surnames. I'm referred to
as both Simon and Simon Riggs in the release notes. Should we have a
policy of first mention uses full name, subsequent mentions just use
first name if there is no confusion by doing so?

--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com

On Wed, Sep 20, 2006 at 05:10:13PM +0100, Simon Riggs wrote:
> Also, not sure what the thoughts are regarding surnames. I'm referred to
> as both Simon and Simon Riggs in the release notes. Should we have a
> policy of first mention uses full name, subsequent mentions just use
> first name if there is no confusion by doing so?

Hrm, I'd assumed that "well known" community members didn't get Surname
mentions... maybe we should just stick to "First Last" everywhere..
--
Jim Nasby jim(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)

Jim C. Nasby wrote:
> On Wed, Sep 20, 2006 at 05:10:13PM +0100, Simon Riggs wrote:
> > Also, not sure what the thoughts are regarding surnames. I'm referred to
> > as both Simon and Simon Riggs in the release notes. Should we have a
> > policy of first mention uses full name, subsequent mentions just use
> > first name if there is no confusion by doing so?
>
> Hrm, I'd assumed that "well known" community members didn't get Surname
> mentions... maybe we should just stick to "First Last" everywhere..

My system has been to use first names if the person appears at the
bottom of the TODO list, else use full name in all references. We refer
to too many people to use full names only on the first reference.

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian wrote:
> Jim C. Nasby wrote:
> > On Wed, Sep 20, 2006 at 05:10:13PM +0100, Simon Riggs wrote:
> > > Also, not sure what the thoughts are regarding surnames. I'm referred to
> > > as both Simon and Simon Riggs in the release notes. Should we have a
> > > policy of first mention uses full name, subsequent mentions just use
> > > first name if there is no confusion by doing so?
> >
> > Hrm, I'd assumed that "well known" community members didn't get Surname
> > mentions... maybe we should just stick to "First Last" everywhere..
>
> My system has been to use first names if the person appears at the
> bottom of the TODO list, else use full name in all references. We refer
> to too many people to use full names only on the first reference.

The problem is that the release notes don't contain the bottom of the
TODO list.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Simon Riggs wrote:
> On Fri, 2006-09-15 at 15:37 -0400, Bruce Momjian wrote:
> > I have completed my first pass over the release notes and Tom has made
> > some additions:
> >
> > http://momjian.postgresql.org/cgi-bin/pgrelease
> >
> > I will probably go over them again in a few hours, update them to
> > current CVS, then move them into our SGML documentation by Monday.
>
> We talk about "standby point-in-time-recovery (PITR) servers" in the
> release notes, but in the docs PITR has now been replaced by Continuous
> Archiving and we talk about Warm Standby servers.
>
> Can we call them Warm Standby servers? That makes more sense for the
> general reader and matches the docs.

Agreed. Updated.

> Also, not sure what the thoughts are regarding surnames. I'm referred to
> as both Simon and Simon Riggs in the release notes. Should we have a
> policy of first mention uses full name, subsequent mentions just use
> first name if there is no confusion by doing so?

OK, changed to "Simon", but am open to making more wholesale changes.

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +