From: | Rajesh Kumar Mallah <mallah(at)trade-india(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org, "Shridhar Daithankar" <shridhar_daithankar(at)persistent(dot)co(dot)in> |
Subject: | Re: Why performance improvement on converting subselect to a function ? |
Date: | 2003-07-30 07:24:49 |
Message-ID: | 200307301254.49159.mallah@trade-india.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)trade-india(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-07-30 13:51:23 | Re: Why performance improvement on converting subselect to a function ? |
Previous Message | Joe Conway | 2003-07-30 03:51:04 | Re: function returning setof performance question |