Horton

Re: Hash Functions

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: amul sul <sulamul@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Andres Freund <andres@anarazel.de>, Joe Conway <mail@joeconway.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Jeff Davis <pgsql@j-davis.com>, Yugo Nagata <nagata@sraoss.co.jp>
Date: 2017-09-01T02:31:25Z
Lists: pgsql-hackers 
On Thu, Aug 31, 2017 at 8:40 AM, amul sul <sulamul@gmail.com> wrote:
> Fixed in the attached version.

I fixed these up a bit and committed them.  Thanks.

I think this takes care of adding not only the infrastructure but
support for all the core data types, but I'm not quite sure how to
handle upgrading types in contrib.  It looks like citext, hstore, and
several data types provided by isn have hash opclasses, and I think
that there's no syntax for adding a support function to an existing
opclass.  We could add that, but I'm not sure how safe it would be.

TBH, I really don't care much about fixing isn, but it seems like
fixing citext and hstore would be worthwhile.

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

Commits

  1. Introduce 64-bit hash functions with a 64-bit seed.

  2. Create a "sort support" interface API for faster sorting.

  3. Add seven kanji characters defined in the Windows 950 codepage to our