Re: [HACKERS] Cached plans and statement generalization
От | Konstantin Knizhnik |
---|---|
Тема | Re: [HACKERS] Cached plans and statement generalization |
Дата | |
Msg-id | b34902a7-c87c-e6ba-032e-bdf67c56e774@postgrespro.ru обсуждение исходный текст |
Ответ на | RE: [HACKERS] Cached plans and statement generalization ("Yamaji, Ryo" <yamaji.ryo@jp.fujitsu.com>) |
Ответы |
RE: [HACKERS] Cached plans and statement generalization
|
Список | pgsql-hackers |
On 02.08.2018 08:25, Yamaji, Ryo wrote: >> -----Original Message----- >> From: Konstantin Knizhnik [mailto:k.knizhnik@postgrespro.ru] >> Sent: Wednesday, August 1, 2018 4:53 PM >> To: Yamaji, Ryo/山地 亮 <yamaji.ryo@jp.fujitsu.com> >> Cc: PostgreSQL mailing lists <pgsql-hackers@postgresql.org> >> Subject: Re: [HACKERS] Cached plans and statement generalization >> >> I failed to reproduce the problem. >> I used the following non-default configuration parameters: >> >> autoprepare_limit=1 >> autoprepare_threshold=1 >> >> create dummy database: >> >> create table foo(x integer primary key, y integer); insert into foo values >> (generate_series(1,10000), 0); >> >> and run different queries, like: >> >> postgres=# select * from foo where x=1; postgres=# select * from foo >> where x+x=1; postgres=# select * from foo where x+x+x=1; postgres=# >> select * from foo where x+x+x+x=1; ... >> >> and check size of CacheMemoryContext using gdb - it is not increased. >> >> Can you please send me your test? > > I checked not CacheMemoryContext but "plan cache context". > Because I think that the memory context that autoprepare mainly uses is "plan cache context". > > Non-default configuration parameter was used as well as Konstantin. > autoprepare_limit=1 > autoprepare_threshold=1 > > The procedure of the test that I did is shown below. > > create dummy database > create table test (key1 integer, key2 integer, ... , key100 integer); > insert into test values (1, 2, ... , 100); > > And, different queries are executed. > select key1 from test where key1=1 and key2=2 and ... and key100=100; > select key2 from test where key1=1 and key2=2 and ... and key100=100; > select key3 from test where key1=1 and key2=2 and ... and key100=100;... > > And, "plan cache context" was confirmed by using gdb. > > Thank you. Unfortunately expression_tree_walker is not consistent with copyObject: I tried to use this walker to destroy raw parse tree of autoprepared statement, but looks like some nodes are not visited by expression_tree_walker. I have to create separate memory context for each autoprepared statement. New version of the patch is attached.
Вложения
В списке pgsql-hackers по дате отправления: