On Wednesday 14 December 2005 16:47, you wrote: > Kevin Brown <blargity@xxxxxxxxx> 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
