| From: | Jean Baro <jfbaro(at)gmail(dot)com> |
|---|---|
| To: | Michael Lewis <mlewis(at)entrata(dot)com> |
| Cc: | MichaelDBA <MichaelDBA(at)sqlexec(dot)com>, Rick Otten <rottenwindfish(at)gmail(dot)com>, pgsql-performance(at)lists(dot)postgresql(dot)org |
| Subject: | Re: High concurrency same row (inventory) |
| Date: | 2019-07-30 00:26:11 |
| Message-ID: | CA+fQee=E3cGB-2fcGZAmb5dLOgJA6C58Mf2=MBvkq=PC4SGFOw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
[image: image.png]
The dead tuples goes up at a high ratio, but then it gets cleaned.
if you guys need any further information, please let me know!
On Mon, Jul 29, 2019 at 9:06 PM Jean Baro <jfbaro(at)gmail(dot)com> wrote:
> The UPDATE was something like:
>
> UPDATE bucket SET qty_available = qty_available + 1 WHERE bucket_uid =
> 0940850938059380590
>
> Thanks for all your help guys!
>
> On Mon, Jul 29, 2019 at 9:04 PM Jean Baro <jfbaro(at)gmail(dot)com> wrote:
>
>> All the failures come from the Bucket Table (see image below).
>>
>> I don't have access to the DB, neither the code, but last time I was
>> presented to the UPDATE it was changing (incrementing or decrementing)
>> *qty_available*, but tomorrow morning I can be sure, once the developers
>> and DBAs are back to the office. I know it's quite a simple UPDATE.
>>
>> Table is called Bucket:
>> {autovacuum_vacuum_scale_factor=0.01}
>>
>> [image: Bucket.png]
>>
>>
>> On Mon, Jul 29, 2019 at 3:12 PM Michael Lewis <mlewis(at)entrata(dot)com> wrote:
>>
>>> Can you share the schema of the table(s) involved and an example or two
>>> of the updates being executed?
>>>
>>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | MichaelDBA | 2019-07-30 01:13:00 | Re: High concurrency same row (inventory) |
| Previous Message | Jean Baro | 2019-07-30 00:06:57 | Re: High concurrency same row (inventory) |