David Rowley writes:
> So, how about the attached today and I'll email Joseph about walleye
> and see if he can upgrade to a newer minGW version.
WFM. (Note I already cc'd Joseph on this thread.)
regards, tom lane
David Rowley writes:
> On Wed, 25 Nov 2020 at 14:28, Tom Lane wrote:
>> So maybe, rather than hacking up the attribute stuff for
>> a bug that might bite us again anyway in future, we ought
>> to press walleye's owner to install a more recent compiler.
> I think that seems like a better idea. I
On Wed, 25 Nov 2020 at 14:35, David Rowley wrote:
>
> On Wed, 25 Nov 2020 at 14:28, Tom Lane wrote:
> > So maybe, rather than hacking up the attribute stuff for
> > a bug that might bite us again anyway in future, we ought
> > to press walleye's owner to install a more recent compiler.
>
> I thin
On Wed, 25 Nov 2020 at 14:28, Tom Lane wrote:
> So maybe, rather than hacking up the attribute stuff for
> a bug that might bite us again anyway in future, we ought
> to press walleye's owner to install a more recent compiler.
I think that seems like a better idea. I had thoughts about
installin
Alvaro Herrera writes:
>> On Wed, 25 Nov 2020 at 04:55, Tom Lane wrote:
>>> walleye's been failing since this patchset went in:
>>> I have no idea what to make of that, but it looks more like a compiler bug
>>> than anything else.
> Apparently the bug was fixed days after it was reported,
> http
Alvaro Herrera writes:
> On 2020-Nov-24, Tom Lane wrote:
>> I'd make any such fix as narrow as possible (ie MINGW64 only, based on
>> present evidence). It'd be nice to have a compiler version upper bound
>> too, in the hopes that they'd fix it in future. Maybe something like
>> "#if defined(__M
On 2020-Nov-24, Tom Lane wrote:
> David Rowley writes:
> > On Wed, 25 Nov 2020 at 04:55, Tom Lane wrote:
> >> walleye's been failing since this patchset went in:
> >> I have no idea what to make of that, but it looks more like a compiler bug
> >> than anything else.
>
> > I wondered if #if !def
David Rowley writes:
> On Wed, 25 Nov 2020 at 04:55, Tom Lane wrote:
>> walleye's been failing since this patchset went in:
>> I have no idea what to make of that, but it looks more like a compiler bug
>> than anything else.
> I wondered if #if !defined(__MINGW32__) && !defined(__MINGW64__) woul
On Wed, 25 Nov 2020 at 04:55, Tom Lane wrote:
>
> walleye's been failing since this patchset went in:
>
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=walleye&dt=2020-11-24%2000%3A25%3A31
>
> ccache gcc -Wall -Wmissing-prototypes -Wpointer-arith
> -Wdeclaration-after-statement -Werror=
On Wed, 25 Nov 2020 at 04:48, Peter Eisentraut
wrote:
>
> On 2020-11-24 01:52, Dagfinn Ilmari Mannsåker wrote:
> > The Clang documentation¹ suggest an even neater solution, which would
> > eliminate the repetitive empty pg_attribute_foo #defines in the trailing
> > #else/#endif block in commit 1fa
David Rowley writes:
> Pushed.
walleye's been failing since this patchset went in:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=walleye&dt=2020-11-24%2000%3A25%3A31
ccache gcc -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Werror=vla -Wendif-labels
-Wmiss
On 2020-11-24 01:52, Dagfinn Ilmari Mannsåker wrote:
The Clang documentation¹ suggest an even neater solution, which would
eliminate the repetitive empty pg_attribute_foo #defines in the trailing
#else/#endif block in commit 1fa22a43a56e1fe44c7bb3a3d5ef31be5bcac41d:
#ifndef __has_attribute
#defi
David Rowley writes:
> On Tue, 24 Nov 2020 at 12:50, Greg Nancarrow wrote:
>> Hmmm, unfortunately this seems to break my build ...
>
>> I think your commit needs to be fixed based on the following documentation:
>>
>> https://gcc.gnu.org/onlinedocs/cpp/_005f_005fhas_005fattribute.html#g_t_005f_0
On Tue, 24 Nov 2020 at 12:50, Greg Nancarrow wrote:
> Hmmm, unfortunately this seems to break my build ...
> I think your commit needs to be fixed based on the following documentation:
>
> https://gcc.gnu.org/onlinedocs/cpp/_005f_005fhas_005fattribute.html#g_t_005f_005fhas_005fattribute
Agreed.
On Tue, Nov 24, 2020 at 10:06 AM David Rowley wrote:
>
> On Tue, 24 Nov 2020 at 09:36, David Rowley wrote:
> > Well, that makes it look pretty good. If we can get 10-15% on some
> > machines without making things slower on any other machines, then that
> > seems like a good win to me.
>
> Pushed
On Tue, 24 Nov 2020 at 09:36, David Rowley wrote:
> Well, that makes it look pretty good. If we can get 10-15% on some
> machines without making things slower on any other machines, then that
> seems like a good win to me.
Pushed.
Thank you both for reviewing this.
David
On Sat, 21 Nov 2020 at 03:26, Peter Eisentraut
wrote:
>
> I did tests of elog_ereport_attribute_cold_v4.patch on an oldish Mac
> Intel laptop with pgbench scale 1 (default), and then:
>
> pgbench -S -T 60
>
> master: tps = 8251.883229 (excluding connections establishing)
> patched: tps = 9556.836
On 2020-11-03 21:53, David Rowley wrote:
On Tue, 3 Nov 2020 at 20:08, Peter Eisentraut
wrote:
On 2020-09-29 11:26, David Rowley wrote:
I've marked this patch back as waiting for review. It would be good if
someone could run some tests on some intel hardware and see if they
can see any speedup
On Tue, 3 Nov 2020 at 20:08, Peter Eisentraut
wrote:
>
> On 2020-09-29 11:26, David Rowley wrote:
> > I've marked this patch back as waiting for review. It would be good if
> > someone could run some tests on some intel hardware and see if they
> > can see any speedup.
>
> What is the way forward
On 2020-09-29 11:26, David Rowley wrote:
On Wed, 23 Sep 2020 at 08:42, David Rowley wrote:
On Tue, 22 Sep 2020 at 19:08, David Rowley wrote:
I ran another scale=5 TPCH benchmark on v4 against f859c2ffa using gcc
9.3. I'm unable to see any gains with this, however, the results were
pretty noi
On Wed, 23 Sep 2020 at 08:42, David Rowley wrote:
>
> On Tue, 22 Sep 2020 at 19:08, David Rowley wrote:
> > I ran another scale=5 TPCH benchmark on v4 against f859c2ffa using gcc
> > 9.3. I'm unable to see any gains with this, however, the results were
> > pretty noisy. I only ran pgbench for 60
On 2020-09-22 22:42, David Rowley wrote:
On Tue, 22 Sep 2020 at 19:08, David Rowley wrote:
I ran another scale=5 TPCH benchmark on v4 against f859c2ffa using gcc
9.3. I'm unable to see any gains with this, however, the results were
pretty noisy. I only ran pgbench for 60 seconds per query. I'll
On Tue, 22 Sep 2020 at 19:08, David Rowley wrote:
> I ran another scale=5 TPCH benchmark on v4 against f859c2ffa using gcc
> 9.3. I'm unable to see any gains with this, however, the results were
> pretty noisy. I only ran pgbench for 60 seconds per query. I'll likely
> need to run that a bit longe
On Fri, 11 Sep 2020 at 02:01, Peter Eisentraut
wrote:
>
> On 2020-09-06 02:24, David Rowley wrote:
> >> I would add DEBUG1 back into the conditional, like
> >>
> >> if (__builtin_constant_p(elevel) && ((elevel) >= ERROR || (elevel) <=
> >> DEBUG1) ? \
> >
> > hmm, but surely we don't want to move
On 2020-09-06 02:24, David Rowley wrote:
I would add DEBUG1 back into the conditional, like
if (__builtin_constant_p(elevel) && ((elevel) >= ERROR || (elevel) <=
DEBUG1) ? \
hmm, but surely we don't want to move all code that's in the same
branch as an elog(DEBUG1) call into a cold area.
Yea
On Sat, 5 Sep 2020 at 08:36, Peter Eisentraut
wrote:
> Something based on the v4 patch makes sense.
Thanks for having a look at this.
> I would add DEBUG1 back into the conditional, like
>
> if (__builtin_constant_p(elevel) && ((elevel) >= ERROR || (elevel) <=
> DEBUG1) ? \
hmm, but surely we d
On 2020-08-05 05:00, David Rowley wrote:
The 5GB scaled TPC-H test does show some performance gains from the v4
patch and shows an obvious regression from removing the unlikely()
calls too.
Based, mostly on the TPC-H results where performance did improve close
to 2%, I'm starting to think it wou
On Mon, 3 Aug 2020 at 19:54, Michael Paquier wrote:
> Worth noting that the patch set fails to apply. I have moved this
> entry to the next CF, waiting on author.
Thanks.
NB: It's not a patch set. It's 3 different versions of the patch.
They're not all meant to apply at once. Probably the CF bo
On Mon, Jun 29, 2020 at 09:36:56PM +1200, David Rowley wrote:
> I've attached a graph showing the results for the AMD and Intel runs
> and also csv files of the pgbench tps output. I've also attached each
> version of the patch I tested.
>
> It would be good to see some testing done on other hard
On Fri, 26 Jun 2020 at 04:35, Andres Freund wrote:
> On 2020-06-25 13:50:37 +1200, David Rowley wrote:
> > In the attached, I've come up with a way that works. Basically I've
> > just added a function named errstart_cold() that is attributed with
> > __attribute__((cold)), which will hint to the c
Hi,
Thanks for picking this up again!
On 2020-06-25 13:50:37 +1200, David Rowley wrote:
> In the attached, I've come up with a way that works. Basically I've
> just added a function named errstart_cold() that is attributed with
> __attribute__((cold)), which will hint to the compiler to keep
> br
On Wed, Jun 24, 2020 at 9:51 PM David Rowley wrote:
> $ pgbench -n -f pg-tpch/queries/q01.sql -T 120 tpch
>
> Which is about a 1.42% increase in performance. That's not exactly
> groundbreaking, but pretty useful to have if that happens to apply
> across the board for execution performance.
>
> Fo
32 matches
Mail list logo
