Re: move hash_any to utils/hash/hashfn.c - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: move hash_any to utils/hash/hashfn.c
Date
Msg-id 201901290922.jbovb7hky7eh@alvherre.pgsql
Whole thread Raw
In response to Re: move hash_any to utils/hash/hashfn.c  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Hello

On 2019-Jan-25, Andres Freund wrote:

> I hate the current split quite a bit, albeit for somewhat different
> reasons. We make things like tag_hash, uint32_hash unnecessarily more
> expensive by adding an entirely useless external function call. And
> some of these can be fairly hot (e.g. for syscache).  So yea, let's
> move this stuff together.

Here's a patch, but I haven't done anything that would change tag_hash
et al.  Looking at the new hashfn.s, it looks like this:

tag_hash:
.LFB42:
    .loc 1 681 0
    .cfi_startproc
.LVL310:
    .loc 1 682 0
    call    hash_any
.LVL311:
    .loc 1 684 0
    rep ret
    .cfi_endproc

In master, it looks like this instead:

tag_hash:
.LFB96:
    .loc 1 53 0
    .cfi_startproc
.LVL5:
    subq    $8, %rsp
    .cfi_def_cfa_offset 16
    .loc 1 54 0
    call    hash_any@PLT
.LVL6:
    .loc 1 56 0
    addq    $8, %rsp
    .cfi_def_cfa_offset 8
    ret
    .cfi_endproc


I don't know if the change is significant.  Obviously we lost the
subq/addq (probably nothing to be excited about) but there's also the
@PLT in the call ... I don't know what that means.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachment

pgsql-hackers by date:

Previous
From: Konstantin Knizhnik
Date:
Subject: Re: Built-in connection pooler
Next
From: Alvaro Herrera
Date:
Subject: Re: pg_dump multi VALUES INSERT