9.5 release notes

On Thu, Jun 11, 2015 at 9:45 AM, Bruce Momjian <bruce@momjian.us> wrote:

I have committed the first draft of the 9.5 release notes. You can view
the output here:

http://momjian.us/pgsql_docs/release-9-5.html

Thanks for writing the Release notes.

Some comments:

Have pg_basebackup use a tablespace mapping file, to allow for file paths
of 100+ characters in length

I think this is not completely correct. This is mainly done to allow
usage of tar format in Windows when tablespaces are present
in database, although we have eventually done it for both
Windows and Linux in the same way. So how about:

Have pg_basebackup use a tablespace mapping file, to allow usage of tar
format
consistently across all platforms

Also shall we mention about below in Migrations to 9.5 section

"pg_basebackup will not not work in tar mode against 9.4 and older servers,
as we have introduced a new protocol option in that mode."

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

On Thu, Jun 11, 2015 at 1:15 PM, Bruce Momjian <bruce@momjian.us> wrote:

I have committed the first draft of the 9.5 release notes. You can view
the output here:

http://momjian.us/pgsql_docs/release-9-5.html

and it will eventually appear here:

http://www.postgresql.org/docs/devel/static/release.html

I am ready to make suggested adjustments, though I am traveling for
conferences for the next ten days so there might a delay in my replies.

Here are some review comments:
+       <para>
+        RETURN WHERE
+       </para>
What is that?

+       <para>
+        WHAT IS A STATISTICS SNAPSHOT?
+       </para>
+      </listitem>
It defines the last time when the global statistics file of pgstat has
been written. Perhaps documentation should be made clearer.

+       <para>
+        The remote snapshot must have been exported by
+        <function>pg_export_snapshot()</> or been defined as a
+        logical replication slot.  This can be used by parallel
+        <application>pg_dump</> to use a consistent snapshot across
+        <application>pg_dump</> processes.
+       </para>
Perhaps "or been defined when creating a logical replication slot
through a replication connection".

+      <listitem>
+       <para>
+        Simplify <acronym>WAL</> record format (Heikki Linnakangas)
+       </para>
+
+       <para>
+        This allows external tools to more easily process <acronym>WAL</>
+        files.
+       </para>
+      </listitem>
More precision could be brought here. What the new format allows is
actually to track more easily what are the blocks modified for
relations, something possible without having the knowledge of the
record type directly.

+       <para>
+        This is particularly helpful for warm standbys.
+       </para>
"for warm standbys to control the timing at which WAL segment files
are retrieved from a WAL archive."

I think that the following items should be added as well:
- Improvement of file version information for Windows builds (Noah
Misch, Michael Paquier), commit ee9569e. The file version information
was missing for a set of contrib modules as well as a handful of
libraries and binaries (like conversion_procs, zic, pg_regress, etc.).
This item should mention that all the binaries and libraries produced
by a Windows build now contain file version information. This could be
merged as well with this item as both are related:
+       <para>
+        Add icons to all <productname>MSVC</>-built binaries (Noah Misch)
+       </para>
- Move pg_lzcompress and pg_lzdecompress to libpqcommon, commit
40bede54. This was some legwork for wal_compression but external
binary tools can take advantage of using it now more freely. Those
APIs have been reworked as well to be more generic, somewhat similarly
to the interface lz4 exposes to the user.
- Addition of palloc_extended (8c8a886) to give module developers a
fallback plan instead of OOM ERROR that palloc throws mandatorily.
MemoryContextAllocExtended() can be used on another memory context
than the current one similarly (bd4e2fd9). Feel free to discard this
one if this is not appropriate in the release notes.
Regards,
-- 
Michael

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 2015-06-11 PM 01:15, Bruce Momjian wrote:

I have committed the first draft of the 9.5 release notes. You can view
the output here:

http://momjian.us/pgsql_docs/release-9-5.html

and it will eventually appear here:

http://www.postgresql.org/docs/devel/static/release.html

I am ready to make suggested adjustments, though I am traveling for
conferences for the next ten days so there might a delay in my replies.

In the last section E.1.3.11.1. pgbench, there is:

+      <listitem>
+       <para>
+        Add information about buffer pins to <application>pg_buffercache</>
+        display (Andres Freund)
+       </para>
+      </listitem>

Should be moved its own section?

Thanks for working on this!

Regards,
Amit

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 11 June 2015 at 16:15, Bruce Momjian <bruce@momjian.us> wrote:

I have committed the first draft of the 9.5 release notes. You can view
the output here:

http://momjian.us/pgsql_docs/release-9-5.html

Thanks Bruce.

Would you also be able to mention something about f15821e and d222585 ?

Regards

David Rowley

--
David Rowley http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/&gt;
PostgreSQL Development, 24x7 Support, Training & Services

Hi,

On 06/11/15 06:15, Bruce Momjian wrote:

I have committed the first draft of the 9.5 release notes. You can view
the output here:

http://momjian.us/pgsql_docs/release-9-5.html

and it will eventually appear here:

http://www.postgresql.org/docs/devel/static/release.html

I am ready to make suggested adjustments, though I am traveling for
conferences for the next ten days so there might a delay in my replies.

I wonder whether this point:

* Improve hash creation performance (Tomas Vondra, Teodor Sigaev, Tom
Lane)

is really about and 45f6240a, 8cce08f1 and 30d7ae3c. I can't remember or
find other hash-related patches I've been working on.

If that's the case, it really is not about hash creation performance
(except maybe partially the first commit), but about the lookup
performance on the hash table. So it should rather be 'improve hash-join
performance'.

Also, I think the list of authors is wrong. Robert Haas did a lot of
work on those patches, so he should be mentioned there, and I don't
remember Teodor working on this.

But maybe I was working on another patch and managed to forget about it.

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Thu, Jun 11, 2015 at 10:20:13AM +0530, Amit Kapila wrote:

On Thu, Jun 11, 2015 at 9:45 AM, Bruce Momjian <bruce@momjian.us> wrote:

I have committed the first draft of the 9.5 release notes.� You can view
the output here:

� � � � http://momjian.us/pgsql_docs/release-9-5.html

Thanks for writing the Release notes.

Some comments:

Have pg_basebackup use a tablespace mapping file, to allow for file paths of
100+ characters in length

I think this is not completely correct. This is mainly done to allow
usage of tar format in Windows when tablespaces are present
in database, although we have eventually done it for both
Windows and Linux in the same way.� So how about:�

Have pg_basebackup use a tablespace mapping file, to allow usage of tar format
consistently across all platforms

Actually, the file fixes 100+ char on all platforms _and_ Windows symbolic links:

Map basebackup tablespaces using a tablespace_map file

Windows can't reliably restore symbolic links from a tar format, so
instead during backup start we create a tablespace_map file, which is
used by the restoring postgres to create the correct links in pg_tblspc.
The backup protocol also now has an option to request this file to be
included in the backup stream, and this is used by pg_basebackup when
operating in tar mode.

This is done on all platforms, not just Windows.

This means that pg_basebackup will not not work in tar mode against 9.4
and older servers, as this protocol option isn't implemented there.

Amit Kapila, reviewed by Dilip Kumar, with a little editing from me.

(Andrew Dunstan)
[72d422a52] 2015-05-12 09:29:10 -0400

pg_basebackup -F t now succeeds with a long symlink target

Error when creating names too long for tar format

The tar format (at least the version we are using), does not support
file names or symlink targets longer than 99 bytes. Until now, the tar
creation code would silently truncate any names that are too long. (Its
original application was pg_dump, where this never happens.) This
creates problems when running base backups over the replication
protocol.

The most important problem is when a tablespace path is longer than 99
bytes, which will result in a truncated tablespace path being backed up.
Less importantly, the basebackup protocol also promises to back up any
other files it happens to find in the data directory, which would also
lead to file name truncation if someone put a file with a long name in
there.

Now both of these cases result in an error during the backup.

Add tests that fail when a too-long file name or symlink is attempted to
be backed up.

Reviewed-by: Robert Hass <robertmhaas@gmail.com>

(Peter Eisentraut)
[23a78352c] 2015-02-24 13:41:07 -0500

Also shall we mention about below in Migrations to 9.5 section

"pg_basebackup will not not work in tar mode against 9.4�and older servers,
�as we have introduced a new protocol option in that mode."

Yes, added. The attached, applied patch has both of these mentions, and
mentions 'tar' mode.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

On Thu, Jun 11, 2015 at 01:54:23PM +0900, Michael Paquier wrote:

On Thu, Jun 11, 2015 at 1:15 PM, Bruce Momjian <bruce@momjian.us> wrote:

I have committed the first draft of the 9.5 release notes. You can view
the output here:

http://momjian.us/pgsql_docs/release-9-5.html

and it will eventually appear here:

http://www.postgresql.org/docs/devel/static/release.html

I am ready to make suggested adjustments, though I am traveling for
conferences for the next ten days so there might a delay in my replies.

Here are some review comments:
+       <para>
+        RETURN WHERE
+       </para>
What is that?

It says the OID is returned, but where? I don't see it in psql.

+       <para>
+        WHAT IS A STATISTICS SNAPSHOT?
+       </para>
+      </listitem>
It defines the last time when the global statistics file of pgstat has
been written. Perhaps documentation should be made clearer.

Update with this text:

This represents the last time the snapshot files was written to
the file system.

+       <para>
+        The remote snapshot must have been exported by
+        <function>pg_export_snapshot()</> or been defined as a
+        logical replication slot.  This can be used by parallel
+        <application>pg_dump</> to use a consistent snapshot across
+        <application>pg_dump</> processes.
+       </para>
Perhaps "or been defined when creating a logical replication slot
through a replication connection".

Sure, updated paragraph:

The remote snapshot must have been exported by
<function>pg_export_snapshot()</> or been defined when creating
a logical replication slot. This can be used by parallel
<application>pg_dump</> to use a consistent snapshot across
<application>pg_dump</> processes.

+      <listitem>
+       <para>
+        Simplify <acronym>WAL</> record format (Heikki Linnakangas)
+       </para>
+
+       <para>
+        This allows external tools to more easily process <acronym>WAL</>
+        files.
+       </para>
+      </listitem>
More precision could be brought here. What the new format allows is
actually to track more easily what are the blocks modified for
relations, something possible without having the knowledge of the
record type directly.

OK, new text:

This allows external tools to more easily track what blocks
are modified.

+       <para>
+        This is particularly helpful for warm standbys.
+       </para>
"for warm standbys to control the timing at which WAL segment files
are retrieved from a WAL archive."

That feels redundant to the major description of the item.

I think that the following items should be added as well:
- Improvement of file version information for Windows builds (Noah
Misch, Michael Paquier), commit ee9569e. The file version information
was missing for a set of contrib modules as well as a handful of
libraries and binaries (like conversion_procs, zic, pg_regress, etc.).
This item should mention that all the binaries and libraries produced
by a Windows build now contain file version information. This could be
merged as well with this item as both are related:
+       <para>
+        Add icons to all <productname>MSVC</>-built binaries (Noah Misch)
+       </para>

OK, merged into the existing item:

Add icons to all <productname>MSVC</>-built binaries and version
information to all <systemitem class="osname">MS Windows</>
binaries (Noah Misch)

- Move pg_lzcompress and pg_lzdecompress to libpqcommon, commit
40bede54. This was some legwork for wal_compression but external
binary tools can take advantage of using it now more freely. Those
APIs have been reworked as well to be more generic, somewhat similarly
to the interface lz4 exposes to the user.

Uh, do we actually want to document that API for users? I didn't think so.

- Addition of palloc_extended (8c8a886) to give module developers a
fallback plan instead of OOM ERROR that palloc throws mandatorily.
MemoryContextAllocExtended() can be used on another memory context
than the current one similarly (bd4e2fd9). Feel free to discard this
one if this is not appropriate in the release notes.

Same question. I am happy to mention it, but if we mention it, we are
encouraging people to use it.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Thu, Jun 11, 2015 at 02:00:08PM +0900, Amit Langote wrote:

On 2015-06-11 PM 01:15, Bruce Momjian wrote:

I have committed the first draft of the 9.5 release notes. You can view
the output here:

http://momjian.us/pgsql_docs/release-9-5.html

and it will eventually appear here:

http://www.postgresql.org/docs/devel/static/release.html

I am ready to make suggested adjustments, though I am traveling for
conferences for the next ten days so there might a delay in my replies.

In the last section E.1.3.11.1. pgbench, there is:

+      <listitem>
+       <para>
+        Add information about buffer pins to <application>pg_buffercache</>
+        display (Andres Freund)
+       </para>
+      </listitem>

Should be moved its own section?

Oops, wrong section. Moved. Thanks.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Thu, Jun 11, 2015 at 05:16:07PM +1200, David Rowley wrote:

On 11 June 2015 at 16:15, Bruce Momjian <bruce@momjian.us> wrote:

I have committed the first draft of the 9.5 release notes.� You can view
the output here:

� � � � http://momjian.us/pgsql_docs/release-9-5.html

Thanks Bruce.

Would you also be able to mention something about�f15821e and�d222585 ?

I am going to defer to Tom on that. I have added optimizer changes in
the past but he didn't feel it made sense unless there was some
user-visible change.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Thu, Jun 11, 2015 at 02:16:59PM +0200, Tomas Vondra wrote:

Hi,

On 06/11/15 06:15, Bruce Momjian wrote:

I have committed the first draft of the 9.5 release notes. You can view
the output here:

http://momjian.us/pgsql_docs/release-9-5.html

and it will eventually appear here:

http://www.postgresql.org/docs/devel/static/release.html

I am ready to make suggested adjustments, though I am traveling for
conferences for the next ten days so there might a delay in my replies.

I wonder whether this point:

* Improve hash creation performance (Tomas Vondra, Teodor Sigaev, Tom
Lane)

is really about and 45f6240a, 8cce08f1 and 30d7ae3c. I can't
remember or find other hash-related patches I've been working on.

If that's the case, it really is not about hash creation performance
(except maybe partially the first commit), but about the lookup
performance on the hash table. So it should rather be 'improve
hash-join performance'.

That is a merged item; here is the other one;

Improve hash_create's API for selecting simple-binary-key hash functions.

Previously, if you wanted anything besides C-string hash keys, you had to
specify a custom hashing function to hash_create(). Nearly all such
callers were specifying tag_hash or oid_hash; which is tedious, and rather
error-prone, since a caller could easily miss the opportunity to optimize
by using hash_uint32 when appropriate. Replace this with a design whereby
callers using simple binary-data keys just specify HASH_BLOBS and don't
need to mess with specific support functions. hash_create() itself will
take care of optimizing when the key size is four bytes.

This nets out saving a few hundred bytes of code space, and offers
a measurable performance improvement in tidbitmap.c (which was not
exploiting the opportunity to use hash_uint32 for its 4-byte keys).
There might be some wins elsewhere too, I didn't analyze closely.

In future we could look into offering a similar optimized hashing function
for 8-byte keys. Under this design that could be done in a centralized
and machine-independent fashion, whereas getting it right for keys of
platform-dependent sizes would've been notationally painful before.

For the moment, the old way still works fine, so as not to break source
code compatibility for loadable modules. Eventually we might want to
remove tag_hash and friends from the exported API altogether, since there's
no real need for them to be explicitly referenced from outside dynahash.c.

Teodor Sigaev and Tom Lane

(Tom Lane)
[4a14f13a0] 2014-12-18 13:36:36 -0500

Also, I think the list of authors is wrong. Robert Haas did a lot of
work on those patches, so he should be mentioned there, and I don't
remember Teodor working on this.

But maybe I was working on another patch and managed to forget about it.

New text:

Improve hash creation and lookup performance (Tomas Vondra,
Teodor Sigaev, Tom Lane, Robert Haas)

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Thu, Jun 11, 2015 at 11:32 AM, Bruce Momjian <bruce@momjian.us> wrote:

Improve hash creation and lookup performance (Tomas Vondra,
Teodor Sigaev, Tom Lane, Robert Haas)

I suggest haveing two separate items. One of those is about the Hash
executor node and the other is about our dynahash stuff. So they're
completely different code bases.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Thu, Jun 11, 2015 at 12:13:26PM -0400, Robert Haas wrote:

On Thu, Jun 11, 2015 at 11:32 AM, Bruce Momjian <bruce@momjian.us> wrote:

Improve hash creation and lookup performance (Tomas Vondra,
Teodor Sigaev, Tom Lane, Robert Haas)

I suggest haveing two separate items. One of those is about the Hash
executor node and the other is about our dynahash stuff. So they're
completely different code bases.

OK, can you give me some text? Do users really care which part it is
in?

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Bruce Momjian <bruce@momjian.us> writes:

On Thu, Jun 11, 2015 at 05:16:07PM +1200, David Rowley wrote:

Would you also be able to mention something about�f15821e and�d222585 ?

I am going to defer to Tom on that. I have added optimizer changes in
the past but he didn't feel it made sense unless there was some
user-visible change.

I'd be inclined to document both of those. We mentioned outer join
removal when it was first added, in 9.0, so making a significant
improvement in it seems worthy of mention also. Both of these things
are "user visible" to the extent that they affect EXPLAIN output.

I'm not sure whether we need to document the semantic hazard that the
second commit message worries about.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Robert Haas <robertmhaas@gmail.com> writes:

On Thu, Jun 11, 2015 at 11:32 AM, Bruce Momjian <bruce@momjian.us> wrote:

Improve hash creation and lookup performance (Tomas Vondra,
Teodor Sigaev, Tom Lane, Robert Haas)

I suggest haveing two separate items. One of those is about the Hash
executor node and the other is about our dynahash stuff. So they're
completely different code bases.

As far as 4a14f13a0 goes, I would think that ought to be mentioned under
"Source Code" since it's a change in a rather widely used API. I doubt
that the performance aspect of it is really all that exciting to end
users, but third-party modules calling the dynahash code would care.
The hash join changes are a completely different thing.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Thu, Jun 11, 2015 at 12:14 PM, Bruce Momjian <bruce@momjian.us> wrote:

On Thu, Jun 11, 2015 at 12:13:26PM -0400, Robert Haas wrote:

On Thu, Jun 11, 2015 at 11:32 AM, Bruce Momjian <bruce@momjian.us> wrote:

Improve hash creation and lookup performance (Tomas Vondra,
Teodor Sigaev, Tom Lane, Robert Haas)

I suggest haveing two separate items. One of those is about the Hash
executor node and the other is about our dynahash stuff. So they're
completely different code bases.

OK, can you give me some text? Do users really care which part it is
in?

One item should say something like:

Improve hash join performance.

The Teodor/Tom thing should say something like:

Improve the performance of various in-memory hash tables. In
particular, this can improve the performance of bitmap index scans.

I assume users would view those as separate things.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 06/10/2015 09:50 PM, Amit Kapila wrote:

Also shall we mention about below in Migrations to 9.5 section

"pg_basebackup will not not work in tar mode against 9.4 and older servers,
as we have introduced a new protocol option in that mode."

AFAIK, pg_basebackup has never worked across versions. So there's no
reason for this note.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Thu, Jun 11, 2015 at 8:56 PM, Josh Berkus <josh@agliodbs.com> wrote:

On 06/10/2015 09:50 PM, Amit Kapila wrote:

Also shall we mention about below in Migrations to 9.5 section

"pg_basebackup will not not work in tar mode against 9.4 and older

servers,

as we have introduced a new protocol option in that mode."

AFAIK, pg_basebackup has never worked across versions. So there's no
reason for this note.

It has. The resulting backup has not been usable cross version, but
pg_basebackup itself has. Though not always, and I'm not sure we've ever
claimed it was supported, but it has worked.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

On Wed, Jun 10, 2015 at 9:15 PM, Bruce Momjian <bruce@momjian.us> wrote:

I have committed the first draft of the 9.5 release notes. You can view
the output here:

+      <listitem>
+       <para>
+        Improve the speed of sorting character and numeric fields (Robert
+        Haas, Peter Geoghegan, Andrew Gierth)
+       </para>
+      </listitem>

A few comments on this.

First of all, I think it should be separately noted that the
sortsupport infrastructure is now used in virtually all places where
it's useful (see commit 5ea86e6e6). So for example, CREATE INDEX on
integer columns ought to be notably faster (and CLUSTER, too). The 9.2
era sortsupport stuff was simply never adopted to do that until now.
That has nothing to do with abbreviated keys, except that the idea of
abbreviated keys gave me a strong reason to care about sortsupport a
lot more. But commit 5ea86e6e6 predates abbreviated keys, and is
certainly independently useful (this really should have made it into
9.2).

Secondly, Robert didn't credit himself as an author in his commit
message for the abbreviated keys infrastructure + text opclass support
*at all*. However, I think that Robert should be listed as a secondary
author of the abbreviated keys infrastructure, and that he would agree
that I am clearly the primary author. Andrew Gierth did work on the
datum case for sortsupport + abbreviation, so I agree he should be
listed as a secondary author of the infrastructure too, after Robert.

I think there should be a total of 4 items related to sorting. The
wording I come up with may not be appropriate, but will give you an
idea:

* Allow sorting to be performed by inlined, non-SQL-callable
comparison functions for CREATE INDEX, REINDEX and CLUSTER operations
based on a B-Tree operator class. (5ea86e6e6 -- Geoghegan)

* Add abbreviated key sorting infrastructure. This allows B-Tree
operator classes to provide compact abbreviated representations of
pass-by-reference types which are sorted with inexpensive comparisons.
This makes sort operations with support for the infrastructure very
significantly faster in the common case where most comparisons can be
resolved with the abbreviated representation alone. (4ea51cdfe85 --
Geoghegan, Haas, Gierth, with Gierth's contribution coming from
78efd5c1 alone)

* Add sortsupport (support for non-SQL callable interface for
comparators) with abbreviation capability to text/varlena operator
class. This significantly accelerates sorting on text columns.
(4ea51cdfe85 too, but also b34e37bf. Worth noting separately IMV.
Geoghegan, Haas).

* Add sortsupport (support for non-SQL callable interface for
comparators) with abbreviation capability to numeric operator class.
This significantly accelerates sorting on numeric columns. (abd94bcac,
Gierth)

I'm not sure if it's worth mentioning the "cheap equality for text"
commit (e246b3d6eac09). I guess that it probably is, because it will
help with things like index scans, too. Arguably that isn't a sorting
thing (it's certainly not *just* a sorting thing).

I've blogged on the abbreviated key stuff quite a bit, which may be
useful should you require additional background information:

http://pgeoghegan.blogspot.com/2015/01/abbreviated-keys-exploiting-locality-to.html

http://pgeoghegan.blogspot.com/2015/04/abbreviated-keys-for-numeric-to.html

Thanks
--
Peter Geoghegan

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Thu, Jun 11, 2015 at 1:23 PM, Peter Geoghegan <pg@heroku.com> wrote:

* Add sortsupport (support for non-SQL callable interface for
comparators) with abbreviation capability to text/varlena operator
class. This significantly accelerates sorting on text columns.
(4ea51cdfe85 too, but also b34e37bf. Worth noting separately IMV.
Geoghegan, Haas).

Also, note that there is no character(n) support for abbreviation as
yet (nor is there any contrib/citext support), so it's not quite true
that the sorting stuff accelerates sorts on "character fields".

--
Peter Geoghegan

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers