Re: Annotated release notes

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > OK, I have committed changes to release.sgml so most complex entries
> > have a paragraph describing the change.  You can see the result at:
> >     http://candle.pha.pa.us/main/writings/pgsql/sgml/release.html#RELEASE-7-4
> > I need people to check this and help me with the items marked 'bjm'.
>
> Okay, a few comments ...
>
> <listitem><para> IN/NOT IN subqueries are now much more efficient</para>
>   <para>
>    In previous releases, IN/NOT IN subqueries were joined to the
>    upper query by sequentially scanning the subquery looking for
>    a join.  The 7.4 code uses the same sophisticated techniques
>    used by ordinary joins and so is much faster, and is now faster
>    than EXISTS subqueries.
>   </para>
> </listitem>
>
> This might be overstatement.  How about "... is much faster.  An IN
> will now usually be as fast as or faster than an equivalent EXISTS
> subquery; this reverses the conventional wisdom that applied to previous
> Postgres releases."
>

Done.


> <listitem><para> Improved GROUP BY processing by using hash buckets</para>
>   <para>
>    In previous releases, GROUP BY totals were accumulated by
>    sequentially scanning the list of groups looking for a match;
>    the 7.4 code places GROUP BY values in hash buckets so the
>    proper match can be found much quicker.  This is particularly
>    significant in speeding up queries that have a large
>    number of distinct GROUP BY values.
>   </para>
> </listitem>
>
> This is backwards.  I suggest "In previous releases, GROUP BY required
> sorting the input data to bring group members together.  7.4 can do it
> that way, or can accumulate data into per-group hash buckets in-memory.
> The hash technique avoids a sort and so can be much faster, if the
> number of distinct GROUP BY values is not too large to fit in memory."

Done.

> <listitem><para> ANSI joins are now better optimized</para>
>    <para>
>     Prior releases evaluated ANSI join syntax only in the order
>     specified by the query;  7.4 allows full optimization of
>     queries using ANSI join syntax, meaning the optimizer considers
>     all possible join orderings and chooses the most efficient.
>    </para>
> </listitem>
>
> This is correct only for inner joins.  Outer joins still follow the
> syntax-implied ordering.  Not sure what the best rewording is.
>
> <listitem><para> Full support for IPv6 connections and IPv6 address
> data types</para>
>    <para>
>     Prior releases allowed only IPv6 connections and IP data types only
>     supported IPv4 addresses. This release adds full IPv6 support in
>     both of these areas.
>    </para>
> </listitem>
>
> Surely "allowed only IPv4 connections".

Yep, fixed.


> <listitem><para> New protocol improves connection speed/reliability,
> and adds error codes, status information, a binary protocol, error
> reporting verbosity, and cleaner startup packets.</para>
> </listitem>
>
> I dunno anything about improving connection speed/reliability.  How
> about "New client-to-server protocol adds error codes, more status
> information, better support for binary data transmission, parameter
> values separated from SQL commands, prepared statements available at the
> protocol level, clean recovery from COPY failures, and cleaner startup
> packets.  The older protocol is still supported by both servers and
> clients."

Updated with your text.

I thought connections were faster because we passed fewer packets on
startup, and I thought you measured a speed improvement in connection
startup time.  Am I remembering wrong?


>
> <listitem><para>Align shared buffers on 32-byte boundary for copy speed improvement (Manfred Spraul)</para>
>    <para>
>     Certain CPU's perform faster data copies when addresses are 32-bit
>     aligned.
>    </para>
>    </listitem>
>
> bit -> byte

Fixed.

> <listitem><para>Fix subquery aggregates of upper query columns to match SQL spec. (Tom)</para>
>    <para>
>     bjm
>    </para>
>    </listitem>
>
> Try:
>
> Fix aggregates in subqueries to match SQL spec
>
> The SQL spec says that an aggregate function appearing within a nested
> subquery belongs to the outer query if its argument contains only
> outer-query variables.  Prior PG releases did not handle this fine point
> correctly.

Updated.

> <listitem><para>Add option to prevent auto-addition of tables referenced in query (Nigel J.
>   Andrews)  </para>
>      <para>
>       By default, tables mentioned in the query are automatically added
>       to the FROM clause if they are not already there. This option
>       disabled that behavior.
>      </para>
>    </listitem>
>
> I'd suggest "... not already there.  This is compatible with
> historical Postgres behavior but is contrary to the SQL spec.
> This option allows selecting spec-compatible behavior."


Updated.

> <listitem><para>Multiple pggla_dump fixes, including tar format and large objects</para></listitem>
>
> "pggla_dump"?

Sure, you know, pggla_dump. :-)   Fixed.

> <listitem><para>Syntax errors now reported as 'syntax error' rather than 'parse error' (Tom)</para></listitem>
>
> Is it worth giving this its own bullet point?  It's far down in the
> noise compared to all the other message rewordings.

I added it to the compatbility section at the top.

--
  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