| From: | "Yamaji, Ryo" <yamaji(dot)ryo(at)jp(dot)fujitsu(dot)com> |
|---|---|
| To: | 'Konstantin Knizhnik' <k(dot)knizhnik(at)postgrespro(dot)ru> |
| Cc: | PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | RE: [HACKERS] Cached plans and statement generalization |
| Date: | 2018-09-28 08:45:22 |
| Message-ID: | 9A6E5062D5D4DB458C80C2B2920BD71D5ECEB5@g01jpexmbkw23 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tuesday, August 7, 2018 at 0:36 AM, Konstantin Knizhnik wrote:
> I have registered the patch for next commitfest.
> For some reasons it doesn't find the latest autoprepare-10.patch and still
> refer to autoprepare-6.patch as the latest attachement.
I'm sorry for the late reply. I'm currently reviewing autoprepare.
I could not make it in time for the commit fests in September,
but I will continue to review for the next commitfest.
Performance tests are good results. The results are shown below.
pgbench -s 100 -c 8 -t 10000 -S (average of 3 trials)
- all autoprepare statements use same memory context.
18052.22706 TPS
- each autoprepare statement use separate memory context.
18607.95889 TPS
- calculate memory usage (autoprepare_memory_limit)
19171.60457 TPS
From the above results, I think that adding/changing functions
will not affect performance. I am currently checking the behavior
when autoprepare_memory_limit is specified.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2018-09-28 08:48:33 | Re: executor relation handling |
| Previous Message | Amit Langote | 2018-09-28 08:28:58 | Re: executor relation handling |