[PERFORM] performance on a querry with many group by's any way to speed it up?

2005-05-20 Thread Joel Fradkin
explain analyze SELECT audit , store , question , month , year , week , weekday , myaudittotalscore , active , auditnum , answer , quarter , y_n , region , district , audittype , status , keyedby , questiondisplay , qtext , qdescr , answerdisplay , answertext , customauditnum , dateaudittak

[PERFORM] cant seem to post the explain

2005-05-20 Thread Joel Fradkin
Sorry I tried a few times to break this email up (guess there must be a size limit?). Any one interested in seeing the explain for the speed of many group by’s question just email me.   Basically the sql is built by a dynamic cube product from data dynamics. I can edit it prior to it ru

Re: [PERFORM] Tuning planner cost estimates

2005-05-20 Thread Jim C. Nasby
On Thu, May 19, 2005 at 09:31:47AM -0700, Josh Berkus wrote: > > In the > > case of testing index scans, we need to be able to vary correlation, > > which so far I've been doing by ordering by different columns. I suspect > > it will also be important to test with different tuple sizes. There's > >

Re: [PERFORM] Tuning planner cost estimates

2005-05-20 Thread Tom Lane
"Jim C. Nasby" <[EMAIL PROTECTED]> writes: > On Thu, May 19, 2005 at 09:31:47AM -0700, Josh Berkus wrote: >> can test our formula for accuracy and precision. However, such a formula >> *does* need to take into account concurrent activity, updates, etc ... that >> is, it needs to approximately es

Re: [PERFORM] Tuning planner cost estimates

2005-05-20 Thread Jim C. Nasby
On Fri, May 20, 2005 at 04:47:38PM -0400, Tom Lane wrote: > "Jim C. Nasby" <[EMAIL PROTECTED]> writes: > > On Thu, May 19, 2005 at 09:31:47AM -0700, Josh Berkus wrote: > >> can test our formula for accuracy and precision. However, such a formula > >> *does* need to take into account concurrent ac

Re: [PERFORM] Tuning planner cost estimates

2005-05-20 Thread Jim C. Nasby
On Fri, May 20, 2005 at 03:23:16PM -0700, Josh Berkus wrote: > Jim, > > > Well, that raises an interesting issue, because AFAIK none of the cost > > estimate functions currently do that. Heck, AFAIK even the piggyback > > seqscan code doesn't take other seqscans into account. > > Sure. But you'

Re: [PERFORM] Tuning planner cost estimates

2005-05-20 Thread Tom Lane
"Jim C. Nasby" <[EMAIL PROTECTED]> writes: > Does this sound like a reasonable approach? Also, how important do > people think it is to use explain analyze output instead of just doing > SELECT count(*) FROM (query you actually want to test)? (The select > count(*) wrapper is just a means to throw