|From:||"Yamaji, Ryo" <yamaji(dot)ryo(at)jp(dot)fujitsu(dot)com>|
|To:||'Konstantin Knizhnik' <k(dot)knizhnik(at)postgrespro(dot)ru>, "Nagaura, Ryohei" <nagaura(dot)ryohei(at)jp(dot)fujitsu(dot)com>, 'Dmitry Dolgov' <9erthalion6(at)gmail(dot)com>|
|Cc:||PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Bruce Momjian <bruce(at)momjian(dot)us>|
|Subject:||RE: [HACKERS] Cached plans and statement generalization|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On Tue, Jan 29, 2019 at 10:46 AM, Konstantin Knizhnik wrote:
> Rebased version of the patch is attached.
I'm sorry for the late review.
I confirmed behavior of autoprepare-12.patch. It is summarized below.
Expected behavior was shown according to the set value.
However, I think that it is be more kind to describe that autoprepare
hold infinite statements when the setting value of
autoprepare_ (memory_) limit is 0 in the manual.
There is no problem as operation.
I confirmed that I could refer properly.
・autoprepare cache retention period
I confirmed that autoprepared statements were deleted when the set
statement or the DDL statement was executed. Although it differs from
the explicit prepare statements, it does not matter as a autoprepare.
This patch does not confirm the basic performance of autoprepare because
it confirmed that there was no performance problem with the previous
patch (autoprepare-11.patch). However, because it was argued that
performance degradation would occur when prepared statements execute to
a partition table, I expected that autoprepare might exhibit similar
behavior, and measured the performance. I also predicted that the
plan_cache_mode setting does not apply to autoprepare, and we also
measured the plan_cache_mode by conditions.
Below results (this result is TPS)
plan_cache_mode simple simple(autoprepare) prepare
auto 130 121 121.5
force_custom_plan 132.5 90.7 122.7
force_generic_plan 126.7 14.7 24.7
Performance degradation was observed when plan_cache_mode was specified
for autoprepare. Is this behavior correct? I do not know why this is the
Below performance test procedure
drop table if exists rt;
create table rt (a int, b int, c int) partition by range (a);
select 'create table rt' || x::text || ' partition of rt for values from (' ||
(x)::text || ') to (' || (x+1)::text || ');' from generate_series(0, 1024) x;
pgbench -p port -T 60 -c 1 -n -f test.sql (-M prepared) postgres
\set a random (0, 1023)
select * from rt where a = :a;
|Next Message||Tsunakawa, Takayuki||2019-03-19 03:05:58||RE: Libpq support to connect to standby server as priority|
|Previous Message||Kyotaro HORIGUCHI||2019-03-19 02:40:41||Re: Problem with default partition pruning|