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 <br...@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
