On Tue, 13 Sep 2005, Stephen Frost wrote: > * Tom Lane ([EMAIL PROTECTED]) wrote: > > I'm starting to think that we might have to succumb to having a compile > > option "optimize for multiprocessor" or "optimize for single processor". > > It's pretty hard to see how we'd alter a data structure decision like > > this on the fly. > > I'd really hate to see this happen. In this case I don't think the > change you're proposing would have much of an impact on a uniprocessor > machine. Having seperate compile-time options for uniprocessor and > multiprocessor would open the gates for potentially other changes which > *would* have a more serious impact on one or the other when compiled for > the opposite. I think this would be a serious problem for binary > distributions and correspondingly their users.
It does make it painful for distribution/package maintainers but I think the potential benefits for single/multi-CPU architectures are high. It means that our lock intrinsic on uniprocessors can just be a lock/delay loop without any spinning -- which is a complete waste of time if you only have one CPU. Doing this at runtime involvevs some pretty significant uglification of low level code I think. Gavin ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match