| From: | "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> |
|---|---|
| To: | 'David Rowley' <david(dot)rowley(at)2ndquadrant(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, "Imai, Yoshikazu" <imai(dot)yoshikazu(at)jp(dot)fujitsu(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, "Simon Riggs" <simon(at)2ndquadrant(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-07-22 00:47:28 |
| Message-ID: | 0A3221C70F24FB45833433255569204D1FC8389B@G01JPEXMBYT05 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
From: David Rowley [mailto:david(dot)rowley(at)2ndquadrant(dot)com]
> I went back to the drawing board on this and I've added some code that counts
> the number of times we've seen the table to be oversized and just shrinks
> the table back down on the 1000th time. 6.93% / 1000 is not all that much.
I'm afraid this kind of hidden behavior would appear mysterious to users. They may wonder "Why is the same query fast at first in the session (5 or 6 times of execution), then gets slower for a while, and gets faster again? Is there something to tune? Am I missing something wrong with my app (e.g. how to use prepared statements)?" So I prefer v5.
> Of course, not all the extra overhead might be from rebuilding the table,
> so here's a test with the updated patch.
Where else does the extra overhead come from?
Regards
Takayuki Tsunakawa
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2019-07-22 01:05:50 | Re: Fix typos and inconsistencies for HEAD (take 7) |
| Previous Message | Where is Where | 2019-07-21 23:28:50 | Re: new function for tsquery creartion |