On Wednesday 14 December 2005 16:47, you wrote: > Kevin Brown <[EMAIL PROTECTED]> writes: > > I'm running 8.1 installed from source on a Debian Sarge server. I have a > > simple query that I believe I've placed the indexes correctly for, and I > > still end up with a seq scan. It makes sense, kinda, but it should be > > able to use the index to gather the right values. > > I continue to marvel at how many people think that if it's not using an > index it must ipso facto be a bad plan ... > > That plan looks perfectly fine to me. You could try forcing some other > choices by fooling with the planner enable switches (eg set > enable_seqscan = off) but I doubt you'll find much improvement. There > are too many rows being pulled from ordered_products to make an index > nestloop a good idea.
That's fine, so being a postgres novice, as I stated in my original post, what would be the best way to improve performance? Redundant column that's updated via a trigger? I'm asking this list because I'd like to do it right, as opposed to get it done. > regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
