From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: v13: Performance regression related to FORTIFY_SOURCE |
Date: | 2020-04-20 02:48:14 |
Message-ID: | 04e4a526d27db42a71f99dc1c8ced289145f9af4.camel@j-davis.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, 2020-04-19 at 16:19 -0700, Peter Geoghegan wrote:
> Is it possible that the issue has something to do with what the
> compiler knows about the alignment of the tapes back when they were a
> flexible array vs. now, where it's a separate allocation? Perhaps I'm
> over reaching, but it occurs to me that MemSetAligned() is itself
> concerned about the alignment of data returned from palloc(). Could
> be
> a similar issue here, too.
The memcpy() is for the buffer, not the array of LogicalTapes, so I
don't really see how that would happen.
> Some guy on the internet says that microarchitectural issues can make
> __memcpy_avx_unaligned() a lot faster that the "rep movsq"
> instruction
> (which you mentioned was a factor on the other thread) in some cases
> [1]. This explanation sounds kind of plausible.
>
> [1] https://news.ycombinator.com/item?id=12050579
That raises another consideration: perhaps this is not uniformly a
regression, but actually faster in some situations? If so, what
situations?
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2020-04-20 02:48:22 | Re: where should I stick that backup? |
Previous Message | David Rowley | 2020-04-20 01:00:40 | Re: [PATCH] Small optimization across postgres (remove strlen duplicate usage) |