Hey, something to maybe set your mind at ease (because I can't now prove or disprove it, as we've upgraded to postges 8 now and changed our indexing): we had our own sets of indexes on our 1.2 dbmail install. Also, I'd guess the queries you're looking at now are probably all against 2.1 schema/indexes. There could be huge differences because of that, right?
Just optimize it to whatever looks the best right now. We're planning on upgrading to 2.2(ish) sometime fairly soon, so I'd mostly ignore our 1.2 results. On Fri, 2006-10-20 at 12:42 -0700, Aaron Stone wrote: > Thanks to Jesse's sleuthing, what's really perplexing is that the > original complaint about status < 2 is that it was killing Pg 7.4. The > updated complaint is that IN (0, 1) is killing Pg 7.4 and < 2 is great. > > On Fri, 2006-10-20 at 21:25 +0200, Paul J Stevens wrote: > > Aaron, > > > > The cost differential is not that high here is it? Or are we logarithmic > > here? > > > > Aaron Stone wrote: > > > Ok, I think we should change the query in db_getmailbox_count to be < 2 > > > because the plan really is a lot less expensive than IN (0, 1). I know > > > this was a thread/bug we had a week or two ago, but it popped into my > > > head today that maybe the planner was guessing the IN (0, 1) meant the > > > same at < 2. It doesn't, and even on Pg 8, it's still more expensive. > > > > status in (0,1): > > > Sort (cost=9.67..9.67 rows=1 width=8) > > status < 2: > > > Sort (cost=8.31..8.31 rows=2 width=8) > > > > > > > > > > _______________________________________________ > Dbmail-dev mailing list > Dbmail-dev@dbmail.org > http://twister.fastxs.net/mailman/listinfo/dbmail-dev -- Jesse Norell - [EMAIL PROTECTED] Kentec Communications, Inc.
