Skip site navigation (1) Skip section navigation (2)

Re: Annotated release notes

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-documentation <pgsql-docs(at)postgresql(dot)org>
Subject: Re: Annotated release notes
Date: 2003-10-31 19:26:38
Message-ID: 200310311926.h9VJQc723546@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-docspgsql-hackers
Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to

Responses

pgsql-docs by date

Next:From: Bruce MomjianDate: 2003-10-31 19:43:10
Subject: Re: [HACKERS] Annotated release notes
Previous:From: Kurt RoeckxDate: 2003-10-31 17:39:47
Subject: Re: [HACKERS] Annotated release notes

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2003-10-31 19:43:10
Subject: Re: [HACKERS] Annotated release notes
Previous:From: Tom LaneDate: 2003-10-31 19:07:01
Subject: Re: Experimental patch for inter-page delay in VACUUM

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group