| From: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
|---|---|
| To: | "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Speed up transaction completion faster after many relations are accessed in a transaction |
| Date: | 2019-02-19 11:57:32 |
| Message-ID: | 8cd83f8e-6bd2-5782-2a8f-ecbeb9d1eb86@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2/12/19 7:33 AM, Tsunakawa, Takayuki wrote:
> ...
>
> This problem was uncovered while evaluating partitioning performance.
> When the application PREPAREs a statement once and then
> EXECUTE-COMMIT repeatedly, the server creates a generic plan on the
> 6th EXECUTE. Unfortunately, creation of the generic plan of
> UPDATE/DELETE currently accesses all partitions of the target table
> (this itself needs improvement), expanding the LOCALLOCK hash table.
> As a result, 7th and later EXECUTEs get slower.
>
> Imai-san confirmed performance improvement with this patch:
>
> https://commitfest.postgresql.org/22/1993/
>
Can you quantify the effects? That is, how much slower/faster does it get?
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Meskes | 2019-02-19 12:14:31 | Re: SQL statement PREPARE does not work in ECPG |
| Previous Message | Michael Paquier | 2019-02-19 11:54:31 | Re: Prepared transaction releasing locks before deregistering its GID |