lementations. What's your opinion?
> --
> Álvaro Herrera https://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sincerely
Mengxing Liu
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
.
> --
> Álvaro Herrerahttps://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sincerely
Mengxing Liu
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
and the performance can't be improved. A chart is
attached. This optimization
can achieve 14% speedup at most.
Do you think this optimization can be accepted?
--
Sincerely
Mengxing Liu
skip-list-for-conflict-tracking.patch
Description: Binary data
--
Sent via pgsql-hackers ma
e performance.
It's hard to explain why...
You can reply directly if you have any questions or comments.
--
Sincerely
Mengxing Liu
HTAB-for-conflict-tracking.patch
Description: Binary data
skip-list-for-conflict-tracking.patch
Description: Binary data
re
tions
RWConflictExists/SetRWConflict is as below.
| | RWConflictExists | SetRWConflict |
| linked list | 1.39% | 0.14% |
| skip list | 1.15% | 0.35% |
According to the suggestions of Alvaro, I'll give a detailed performance
report tomorrow.
--
Sincerely
Mengxing Liu
skip-list-fo
ed by some
mistakes.
When I changed a machine to run the code, this phenomenon didn't happen
anymore..
-Original Messages-
From: "Robert Haas"
Sent Time: 2017-07-29 02:46:47 (Saturday)
To: "Mengxing Liu"
Cc: "Alvaro Herrera" , kgrittn ,
"pgsql-hack
most.
That means, the skip list can work!
Looking forward to your advices.
--
Sincerely
Mengxing Liu
skip-list-for-conflict-tracking.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
using hash table for conflict tracking.
2) reducing the global lock contention
3) using skip list for conflict tracking.
But all of them did not improve the performance. So I'm a little confused now
about what to do next.
Could you please give me any suggestions?
--
Sincerely
Mengxing
s, so two level skip list is
enough now.
I'll make a clean patch after I figure out bugs.
--
Sincerely
Mengxing Liu
ached.
To focus on this issue, I removed other parts of modification.
Do you have any advices for this ?
--
Sincerely
Mengxing Liu
finishedlock.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscrip
why in the next days.
But I'm really looking forward to your advice for my proposal. We can't be too
careful to modify the code related to locks.
--
Sincerely
Mengxing Liu
memory resources.
( because hash table objects also consume memory )
But just for performance, it would be less efficient than my patch.
Because it has to maintain linked lists, besides hash tables. In other words,
it does more works than my patch.
Another point is that removing linked list may
ionFailure,
PreCommit_CheckForSerializationFailure
Sincerely
--
Mengxing Liu
think that's why PG is so slow in high contention environment.
> -Original Messages-
> From: "Robert Haas"
> Sent Time: 2017-06-08 01:30:58 (Thursday)
> To: "Mengxing Liu"
> Cc: kgrittn , "Alvaro Herrera" ,
> "pgsql-hackers@postgresq
> you said this is a CPU graph, that again suggests spinlock contention
> issues.
>
> --
Yes. Is there any other kind of locks besides spinlock? I'm reading locks in PG
now. If all locks are spinlock, the CPU should be used 100%. But now only 50%
CPU are used.
I'
meofday" to profile is really ugly.
Perf lock can only record kernel mutex, and requires kernel support, so I
didn't use it.
Do you have any good idea about profiling time waiting for locks?
> -Original Messages-
> From: "Mengxing Liu"
> Sent Time: 2017-06-05 00
> -Original Messages-
> From: "Kevin Grittner"
> Sent Time: 2017-06-03 01:44:16 (Saturday)
> To: "Alvaro Herrera"
> Cc: "Mengxing Liu" ,
> "pgsql-hackers@postgresql.org"
> Subject: Re: Re: Re: [HACKERS] Re: [GSOC
by LOCK? Is there any chance to get rid of this problem?
BTW, I found that the email is not very convenient, especially when I have
some problem and want to discuss with you.
Would you mind scheduling a meeting every week by Skye, or other instant
message software you like?
I would not take y
about reporting my status once a week?
> What steps will be taken next during the community bonding period.
As I wrote in the proposal, I want to establish the environment and read the
related source code. Do you have any suggestions for me?
--
Mengxing Liu
me shared memory issues, since the structure *must*
> live in shared memory.
>
Thank you. If there is no other problem, I will submit the proposal.
--
Mengxing Liu
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
used in it,
and I cannot estimate how much time it would take.
> -Original Messages-
> From: "Kevin Grittner"
> Sent Time: 2017-03-28 00:16:11 (Tuesday)
> To: "Mengxing Liu"
> Cc: "pgsql-hackers@postgresql.org"
> Subject: Re: [HACKERS] G
rittner"
> Sent Time: 2017-03-25 04:53:36 (Saturday)
> To: "Mengxing Liu"
> Cc: "pgsql-hackers@postgresql.org"
> Subject: Re: [HACKERS] Guidelines for GSoC student proposals / Eliminate
> O(N^2) scaling from rw-conflict tracking in serializable transaction
; completed the project
>
> Note that a student proposal is supposed to be far more detailed
> than the ideas for projects provided by the organization -- those
> are intended to be ideas for what the student might write up as a
> proposal, not ready-to-go proposal
> -Original Messages-
> From: "Kevin Grittner"
> Sent Time: 2017-03-15 23:20:07 (Wednesday)
> To: DEV_OPS
> Cc: "Mengxing Liu" ,
> "pgsql-hackers@postgresql.org"
> Subject: Re: [HACKERS] Re: [GSOC 17] Eliminate O(N^2) scaling from
e simple and easy to implement.
For me, the challenge is profiling the execution. Is there any tools in
PostgreSQL to analysis where is the CPU cycles consumed?
Or I have to instrument and time by myself?
Regards.
--
Mengxing Liu
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> -Original Messages-
> From: "Kevin Grittner"
> Sent Time: 2017-03-12 04:24:29 (Sunday)
> To: "Mengxing Liu"
> Cc: "pgsql-hackers@postgresql.org"
> Subject: Re: [GSOC 17] Eliminate O(N^2) scaling from rw-conflict tracking in
> ser
Hi, all
My name is Mengxing Liu. I am interested in the project "Eliminate O(N^2)
scaling from rw-conflict tracking in serializable transactions”. After
discussing with Kevin off-list, I think it's time to post discussion here. I am
afraid that there are two things that I need
Hi George,
I am Mengxing Liu. Happy to meet someone with the same idea : )
I have been concentrating on it for a long time, reading papers, reading source
codes, and discussing details with Mr Grittner. So I really understand your
passion on it. But definitely I don't want all these ef
28 matches
Mail list logo
