Re: 9.5 release notes - Mailing list 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
besidesC-string hash keys, you had to    specify a custom hashing function to hash_create().  Nearly all such
callerswere specifying tag_hash or oid_hash; which is tedious, and rather    error-prone, since a caller could easily
missthe opportunity to optimize    by using hash_uint32 when appropriate.  Replace this with a design whereby
callersusing 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
hundredbytes of code space, and offers    a measurable performance improvement in tidbitmap.c (which was not
exploitingthe opportunity to use hash_uint32 for its 4-byte keys).    There might be some wins elsewhere too, I didn't
analyzeclosely.    In future we could look into offering a similar optimized hashing function    for 8-byte keys.
Underthis design that could be done in a centralized    and machine-independent fashion, whereas getting it right for
keysof    platform-dependent sizes would've been notationally painful before.    For the moment, the old way still
worksfine, so as not to break source    code compatibility for loadable modules.  Eventually we might want to    remove
tag_hashand friends from the exported API altogether, since there's    no real need for them to be explicitly
referencedfrom 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. +