On Mon, Mar 5, 2018 at 1:26 PM, Konstantin Knizhnik
wrote:
>
> On 03.03.2018 16:44, Amit Kapila wrote:
>>
>> On Thu, Mar 1, 2018 at 1:22 PM, Konstantin Knizhnik
>> wrote:
>>>
>>> On 28.02.2018 16:32, Amit Kapila wrote:
On Mon, Feb 26, 2018 at 8:26 PM, Konstantin Knizhnik
wrote:
>>
On 03.03.2018 16:44, Amit Kapila wrote:
On Thu, Mar 1, 2018 at 1:22 PM, Konstantin Knizhnik
wrote:
On 28.02.2018 16:32, Amit Kapila wrote:
On Mon, Feb 26, 2018 at 8:26 PM, Konstantin Knizhnik
wrote:
Yes, but two notices:
1. Tuple lock is used inside heap_* functions. But not in EvalPlanQu
On Thu, Mar 1, 2018 at 1:22 PM, Konstantin Knizhnik
wrote:
>
> On 28.02.2018 16:32, Amit Kapila wrote:
>>
>> On Mon, Feb 26, 2018 at 8:26 PM, Konstantin Knizhnik
>> wrote:
>
>
> Yes, but two notices:
> 1. Tuple lock is used inside heap_* functions. But not in EvalPlanQualFetch
> where transaction
On 28.02.2018 16:32, Amit Kapila wrote:
On Mon, Feb 26, 2018 at 8:26 PM, Konstantin Knizhnik
wrote:
On 26.02.2018 17:20, Amit Kapila wrote:
Can you please explain, how it can be done easily without extra tuple
locks? I have tried to read your patch but due to lack of comments,
it is not cle
On Mon, Feb 26, 2018 at 8:26 PM, Konstantin Knizhnik
wrote:
>
> On 26.02.2018 17:20, Amit Kapila wrote:
>>
>> Can you please explain, how it can be done easily without extra tuple
>> locks? I have tried to read your patch but due to lack of comments,
>> it is not clear what you are trying to achi
On 26.02.2018 17:20, Amit Kapila wrote:
On Tue, Feb 20, 2018 at 10:34 PM, Konstantin Knizhnik
wrote:
On 20.02.2018 19:39, Simon Riggs wrote:
On 20 February 2018 at 16:07, Konstantin Knizhnik
wrote:
On 20.02.2018 14:26, Simon Riggs wrote:
Try locking the root tid rather than the TID, tha
On 26.02.2018 17:00, Amit Kapila wrote:
On Thu, Feb 15, 2018 at 9:30 PM, Konstantin Knizhnik
wrote:
Hi,
PostgreSQL performance degrades signficantly in case of high contention.
You can look at the attached YCSB results (ycsb-zipf-pool.png) to estimate
the level of this degradation.
Postgres
On Tue, Feb 20, 2018 at 10:34 PM, Konstantin Knizhnik
wrote:
>
>
> On 20.02.2018 19:39, Simon Riggs wrote:
>>
>> On 20 February 2018 at 16:07, Konstantin Knizhnik
>> wrote:
>>>
>>>
>>> On 20.02.2018 14:26, Simon Riggs wrote:
Try locking the root tid rather than the TID, that is at least
On Thu, Feb 15, 2018 at 9:30 PM, Konstantin Knizhnik
wrote:
> Hi,
>
> PostgreSQL performance degrades signficantly in case of high contention.
> You can look at the attached YCSB results (ycsb-zipf-pool.png) to estimate
> the level of this degradation.
>
> Postgres is acquiring two kind of heavy w
On 20.02.2018 19:39, Simon Riggs wrote:
On 20 February 2018 at 16:07, Konstantin Knizhnik
wrote:
On 20.02.2018 14:26, Simon Riggs wrote:
Try locking the root tid rather than the TID, that is at least unique
per page for a chain of tuples, just harder to locate.
As far as I understand, it
On 20 February 2018 at 16:07, Konstantin Knizhnik
wrote:
>
>
> On 20.02.2018 14:26, Simon Riggs wrote:
>>
>> Try locking the root tid rather than the TID, that is at least unique
>> per page for a chain of tuples, just harder to locate.
>>
> As far as I understand, it is necessary to traverse the
On 20.02.2018 14:26, Simon Riggs wrote:
Try locking the root tid rather than the TID, that is at least unique
per page for a chain of tuples, just harder to locate.
As far as I understand, it is necessary to traverse the whole page to
locate root tuple, isn't it?
If so, then I expect it to be
On 20.02.2018 16:42, Simon Riggs wrote:
On 20 February 2018 at 13:19, Konstantin Knizhnik
wrote:
On 20.02.2018 14:26, Simon Riggs wrote:
On 15 February 2018 at 16:00, Konstantin Knizhnik
wrote:
So in heap_acquire_tuplock all competing transactions are waiting for TID
of
the updated versi
On 20 February 2018 at 13:19, Konstantin Knizhnik
wrote:
>
>
> On 20.02.2018 14:26, Simon Riggs wrote:
>>
>> On 15 February 2018 at 16:00, Konstantin Knizhnik
>> wrote:
>>
>>> So in heap_acquire_tuplock all competing transactions are waiting for TID
>>> of
>>> the updated version. When transactio
On 20.02.2018 14:26, Simon Riggs wrote:
On 15 February 2018 at 16:00, Konstantin Knizhnik
wrote:
So in heap_acquire_tuplock all competing transactions are waiting for TID of
the updated version. When transaction which changed this tuple is committed,
one of the competitors will grant this lo
On 15 February 2018 at 16:00, Konstantin Knizhnik
wrote:
> So in heap_acquire_tuplock all competing transactions are waiting for TID of
> the updated version. When transaction which changed this tuple is committed,
> one of the competitors will grant this lock and proceed, creating new
> version
On 16.02.2018 11:59, Michail Nikolaev wrote:
Hello.
Just want to notice - this work also correlates with
https://www.postgresql.org/message-id/CAEepm%3D18buPTwNWKZMrAXLqja1Tvezw6sgFJKPQ%2BsFFTuwM0bQ%40mail.gmail.com paper.
It provides more general way to address the issue comparing to single
Hello.
Just want to notice - this work also correlates with
https://www.postgresql.org/message-id/CAEepm%3D18buPTwNWKZMrAXLqja1Tvezw6sgFJKPQ%2BsFFTuwM0bQ%40mail.gmail.com
paper.
It provides more general way to address the issue comparing to single
optimisations (but they could do the work too, of
18 matches
Mail list logo
