On Tue, 1 Dec 2020 at 02:31, Alexander Korotkov
wrote:
> On Mon, Nov 30, 2020 at 7:00 AM Krunal Bauskar
> wrote:
> > 3. Problem with GCC approach is still a lot of distro don't support gcc
> 9.4 as default.
> > To use this approach:
> > * PGSQL will hav
On Tue, 1 Dec 2020 at 15:16, Alexander Korotkov
wrote:
> On Tue, Dec 1, 2020 at 6:26 AM Krunal Bauskar
> wrote:
> > On Tue, 1 Dec 2020 at 02:31, Alexander Korotkov
> wrote:
> >> BTW, how do you get that required gcc version is 9.4? I've managed to
> >>
t; should produce worse code than the default settings.
>
> Great, thanks.
>
> So, I think the following hypothesis isn't disproved yet.
> 1) On ARM with LSE support, PostgreSQL built with LSE is faster than
> PostgreSQL built wi
On Tue, 1 Dec 2020 at 20:25, Alexander Korotkov
wrote:
> On Tue, Dec 1, 2020 at 3:44 PM Krunal Bauskar
> wrote:
> > I have completed benchmarking with lse.
> >
> > Graph attached.
>
> Thank you for benchmarking.
>
> Now I agree with this comment by T
On Tue, 1 Dec 2020 at 22:19, Tom Lane wrote:
> Alexander Korotkov writes:
> > On Tue, Dec 1, 2020 at 6:19 PM Krunal Bauskar
> wrote:
> >> I would request you guys to re-think it from this perspective to help
> ensure that PGSQL can scale well on ARM.
> >> s_loc
Any updates or further inputs on this.
On Wed, 2 Dec 2020 at 09:27, Krunal Bauskar wrote:
>
>
> On Tue, 1 Dec 2020 at 22:19, Tom Lane wrote:
>
>> Alexander Korotkov writes:
>> > On Tue, Dec 1, 2020 at 6:19 PM Krunal Bauskar
>> wrote:
>> >> I wo
On Thu, 3 Dec 2020 at 21:32, Tom Lane wrote:
> Krunal Bauskar writes:
> > Any updates or further inputs on this.
>
> As far as LSE goes: my take is that tampering with the
> compiler/platform's default optimization options requires *very*
> strong evidence, which
On Tue, 8 Dec 2020 at 14:33, Krunal Bauskar wrote:
>
>
> On Thu, 3 Dec 2020 at 21:32, Tom Lane wrote:
>
>> Krunal Bauskar writes:
>> > Any updates or further inputs on this.
>>
>> As far as LSE goes: my take is that tampering with the
>> com
Wondering if we can take this to completion (any idea what more we could
do?).
On Thu, 10 Dec 2020 at 14:48, Krunal Bauskar
wrote:
>
> On Tue, 8 Dec 2020 at 14:33, Krunal Bauskar
> wrote:
>
>>
>>
>> On Thu, 3 Dec 2020 at 21:32, Tom Lane wrote:
>>
>>&
Amit Khandekar for rigorously performance testing this patch
with different combinations).
[1]: https://godbolt.org/z/jqbEsa
P.S: Sorry if I missed any standard pgsql protocol since I am just starting
with pgsql.
---
Krunal Bauskar
#mysqlonarm
Huawei Technologies
diff --git a/src/include/storage/s_loc
Paquier wrote:
> On Thu, Nov 26, 2020 at 10:00:50AM +0530, Krunal Bauskar wrote:
> > (Thanks to Amit Khandekar for rigorously performance testing this patch
> > with different combinations).
>
> For the simple-update and tpcb-like graphs, do you have any actual
> numbers
On Thu, 26 Nov 2020 at 10:50, Tom Lane wrote:
> Michael Paquier writes:
> > On Thu, Nov 26, 2020 at 10:00:50AM +0530, Krunal Bauskar wrote:
> >> (Thanks to Amit Khandekar for rigorously performance testing this patch
> >> with different combinations).
>
> >
On Thu, 26 Nov 2020 at 16:02, Heikki Linnakangas wrote:
> On 26/11/2020 06:30, Krunal Bauskar wrote:
> > Improving spin-lock implementation on ARM.
> >
> >
> > * Spin-Lock is known to have a signif
ve made some benchmarks on c6gd.16xlarge ec2 instance with graviton2
> processor of 64 virtual CPUs (graphs and raw results are attached).
> I've analyzed two patches: spinlock using cas by Krunal Bauskar, and
> my implementation of lwlock using lwrex/strex. My arm lwlock patch
> has th
On Mon, 30 Nov 2020 at 10:14, Tom Lane wrote:
> Krunal Bauskar writes:
> > So given all the permutations and combinations, I think we could approach
> > the problem as follows:
>
> > * Enable use of CAS as it is known to have optimal performance (vs TAS)
>
> The r
On Mon, 30 Nov 2020 at 11:38, Tom Lane wrote:
> Krunal Bauskar writes:
> > On Mon, 30 Nov 2020 at 10:14, Tom Lane wrote:
> >> The results I posted at [1] seem to contradict this for Apple's new
> >> machines.
>
> > For the results you saw on Mac-Mi
16 matches
Mail list logo