Re: High concurrency same row (inventory)

Поиск
Список
Период
Сортировка
От Jean Baro
Тема Re: High concurrency same row (inventory)
Дата
Msg-id CA+fQeennK4mHkN0Kp5_xFDAU8dK=sY6-=J6ftpJmN9OympOEUg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: High concurrency same row (inventory)  (Jean Baro <jfbaro@gmail.com>)
Список pgsql-performance
Michael Vitale --> No, there is only postgreSQL running in this server... it is in fact an RDS server.

SELECT n_tup_ins as "inserts",n_tup_upd as "updates",n_tup_del as "deletes", n_tup_hot_upd as "hot updates", n_live_tup as "live_tuples", n_dead_tup as "dead_tuples"
FROM pg_stat_user_tables
WHERE schemaname = 'schemaFOO' and relname = 'bucket';

image.png



On Mon, Jul 29, 2019 at 9:26 PM Jean Baro <jfbaro@gmail.com> wrote:
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@gmail.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@gmail.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}

Bucket.png


On Mon, Jul 29, 2019 at 3:12 PM Michael Lewis <mlewis@entrata.com> wrote:
Can you share the schema of the table(s) involved and an example or two of the updates being executed?
Вложения

В списке pgsql-performance по дате отправления:

Предыдущее
От: MichaelDBA
Дата:
Сообщение: Re: High concurrency same row (inventory)
Следующее
От: Mariel Cherkassky
Дата:
Сообщение: A question regarding streaming replication