Re: Why performance improvement on converting subselect to a function ?
От | Rajesh Kumar Mallah |
---|---|
Тема | Re: Why performance improvement on converting subselect to a function ? |
Дата | |
Msg-id | 200307301254.49159.mallah@trade-india.com обсуждение исходный текст |
Ответ на | Re: Why performance improvement on converting subselect to a function ? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Why performance improvement on converting subselect to a function ?
Re: Why performance improvement on converting subselect to a function ? |
Список | pgsql-performance |
Dear Tom, the problem was repeatble in the sense repeated execution of queries made no difference on performance. What lead to degradation was the bumping off of effective_cache_size parameter from 1000 to 64K Can any one point me the recent guide done by Sridhar and Josh i want to see what i mis(read|understood) from there ;-) [ it was on GeneralBits' Home Page ] Anyway the performance gain was from 32 secs to less than a sec what i restored cache size from 64K to 1000. I will post again with more details but at the moment i got to load my data_bank :) Regds Mallah. On Wednesday 30 Jul 2003 3:02 am, Tom Lane wrote: > Rajesh Kumar Mallah <mallah@trade-india.com> writes: > > Tom Lane wrote: > >> Odd. Apparently the planner is picking a better plan in the function > >> context than in the subselect context --- which is strange since it > >> ought to have less information. > > > > [ verbose plan snipped ] > > Well, that sure seems to be the same plan. Curious that the runtime > wasn't about the same. Perhaps the slow execution of the first query > was a caching effect? If you alternate trying the query both ways, > does the speed difference persist? > > regards, tom lane
В списке pgsql-performance по дате отправления: