提高 Postgres 中时间戳列的并发更新性能

Pau*_*tto 1 postgresql concurrency locking update postgresql-9.3

我正在使用一个称为updated_at缓存失效的时间戳列。此处提供有关此特定技术的更多信息。

查询都具有相同的格式

UPDATE "managers" SET "updated_at" = '2014-07-25 15:00:24.212512' WHERE "managers"."id" = 1

问题是此列上的活动过多,导致写入缓慢。我假设减速是由锁定机制引起的。列上没有索引。

我们一直试图通过将可能导致多次更新的操作批处理来缓解这种情况,这确实有所帮助,但整个系统仍然受到影响。

  1. 不同类型的列会更快吗?例如一个整数。
  2. 有什么方法可以不锁定列吗?
  3. 任何其他提示来改善这一点?

我们实际上正在考虑将其移至 redis 并使用 INCR。

                                            表“public.managers”
         专栏 | 类型 | 修饰符
-------------------------+------------------------ -----+-------------------------------------------- -----------------
 身份证 | 整数 | 非空默认 nextval('leads_managers_id_seq'::regclass)
 account_id | 整数 |
 created_at | 没有时区的时间戳 |
 更新时间 | 没有时区的时间戳 |
 通知_收件人| 文字 | 默认 ''::character 变化
 用户名 | 字符变化(255) |
索引:
    “leads_managers_pkey”主键,btree (id)
    "index_leads_managers_on_uuid" UNIQUE, btree (uuid)
    "index_leads_managers_on_account_id" btree (account_id)

Cra*_*ger 5

不同类型的列会更快吗?例如一个整数

不,timestamp并且timestamptz在内部只是无符号的 64 位整数。

有什么方法可以不锁定列吗?

它不会锁定列。它采用弱表锁,除了 DDL 之外不会真正阻塞任何东西,并在您正在更新的行上采用行级锁。

没有办法防止行级锁。它存在是因为没有它的行为和排序并发更新将是未定义的。我们不喜欢 RDBMS 中未定义的行为。

无论如何,它只会阻止同一行的并发更新。

任何其他提示来改善这一点?

没有提供的细节。可能有更好的方法来做你想做的事情,但它可能需要退后几步,寻找解决潜在问题的不同策略。

在缓存失效的特定情况下,我认为您可能需要查看LISTENNOTIFY。再一次,这里没有足够的信息继续下去。