RE: [HACKERS] Cached plans and statement generalization
От | Yamaji, Ryo |
---|---|
Тема | RE: [HACKERS] Cached plans and statement generalization |
Дата | |
Msg-id | 9A6E5062D5D4DB458C80C2B2920BD71D5C471C@g01jpexmbkw23 обсуждение исходный текст |
Ответ на | Re: [HACKERS] Cached plans and statement generalization (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>) |
Ответы |
Re: [HACKERS] Cached plans and statement generalization
|
Список | pgsql-hackers |
> -----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.
В списке pgsql-hackers по дате отправления: