RE: Speed up transaction completion faster after many relations areaccessed in a transaction

Поиск
Список
Период
Сортировка
От Tsunakawa, Takayuki
Тема RE: Speed up transaction completion faster after many relations areaccessed in a transaction
Дата
Msg-id 0A3221C70F24FB45833433255569204D1FC83A75@G01JPEXMBYT05
обсуждение исходный текст
Ответ на Re: Speed up transaction completion faster after many relations areaccessed in a transaction  (David Rowley <david.rowley@2ndquadrant.com>)
Ответы Re: Speed up transaction completion faster after many relations areaccessed in a transaction  (David Rowley <david.rowley@2ndquadrant.com>)
Список pgsql-hackers
From: David Rowley [mailto:david.rowley@2ndquadrant.com]
> For the use case we've been measuring with partitioned tables and the
> generic plan generation causing a sudden spike in the number of
> obtained locks, then having plan_cache_mode = force_custom_plan will
> cause the lock table not to become bloated. I'm not sure there's
> anything interesting to measure there.

I meant the difference between the following two cases, where the query only touches one partition (e.g. SELECT ...
WHEREpkey = value):
 

* plan_cache_mode=force_custom_plan: LocalLockHash won't bloat.  The query execution time is steady.

* plan_cache_mode=auto: LocalLockHash bloats on the sixth execution due to the creation of the generic plan.  The
genericplan is not adopted because its cost is high.  Later executions of the query will suffer from the bloat until
the1006th execution when LocalLockHash is shrunk.
 


Depending on the number of transactions and what each transaction does, I thought the difference will be noticeable or
not.


Regards
Takayuki Tsunakawa



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

Предыдущее
От: Alexander Lakhin
Дата:
Сообщение: Re: Fix typos and inconsistencies for HEAD (take 7)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: POC: converting Lists into arrays