Re: v13: Performance regression related to FORTIFY_SOURCE - Mailing list pgsql-hackers

From Tom Lane
Subject Re: v13: Performance regression related to FORTIFY_SOURCE
Date
Msg-id 1443262.1591321304@sss.pgh.pa.us
Whole thread Raw
In response to Re: v13: Performance regression related to FORTIFY_SOURCE  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: v13: Performance regression related to FORTIFY_SOURCE  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-hackers
Jeff Davis <pgsql@j-davis.com> writes:
> On Thu, 2020-06-04 at 16:35 -0400, Alvaro Herrera wrote:
>> If it is something worth worrying about, let's discuss what's a good
>> fix for it.

> I did post a fix for it, but it's not a very clean fix. I'm slightly
> inclined to proceed with that fix, but I was hoping someone else would
> have a better suggestion.
> How about if I wait another week, and if we still don't have a better
> fix, I will commit this one.

TBH, I don't think we should do this, at least not on the strength of the
evidence you posted so far.  It looks to me like you are micro-optimizing
for one compiler on one platform.  Moreover, you're basically trying to
work around a compiler codegen bug that might not be there next year.

I think what'd make more sense is to file this as a gcc bug ("why doesn't
it remove the useless object size check?") and see what they say about
that.  If the answer is that this isn't a gcc bug for whatever reason,
then we could think about whether we should work around it on the
source-code level.  Even then, I'd want more evidence than has been
presented about this not causing a regression on other toolchains/CPUs.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: significant slowdown of HashAggregate between 9.6 and 10
Next
From: Andres Freund
Date:
Subject: Re: significant slowdown of HashAggregate between 9.6 and 10