On Wed, Oct 16, 2013 at 10:04:29PM +0200, Andres Freund wrote: > On 2013-10-16 15:49:54 -0400, Bruce Momjian wrote: > > On Sat, Oct 12, 2013 at 06:35:00PM -0700, Peter Geoghegan wrote: > > > > - ALPHA (big pain in the ass to get right, nobody uses it anymore) > > > > > > Yes, for many years now ALPHA has only been useful as a way of > > > illustrating how bad it's possible for CPU memory operation reordering > > > considerations to get. So I quite agree. > > > > Are there any optimizations we have avoided, or 'volatile' designations > > added, only for Alpha? > > I am somewhat sure that some of the code we added in the last years > isn't actually correct for alpha (and others actually). It's just that > nobody actually runs on alpha anymore, so nobody notices. > > > Could we improve other things if Alpha support was dropped? > > I think the major thing is that if we're going to add more algorithms > that use less locks - which we'll have to, otherwise our scalability > will get more and more problematic - we'll have to adhere to the > weakest cache coherency model we support. And at least I am not > intelligent/experienced enough to blindly write correct code for Alpha.
Removing support for alpha is a different animal compared to removing support for non-gcc MIPS and most of the others in your list. A hacker wishing to restore support for another MIPS compiler would fill in the assembly code blanks, probably using code right out of an architecture manual. A hacker wishing to restore support for alpha would find himself auditing every lock-impoverished algorithm in the backend. At the same time, as you suggest, the benefit to general PostgreSQL development from dropping alpha is greater in the same way. Dropping non-gcc MIPS reduces effort to complete the initial patch that adds the atomic primitives; dropping alpha reduces effort to implement every future algorithm that uses barriers. I do think dropping support for alpha is the right decision. That's a firm and likely one-way downgrade of support, much like we've done for compilers with no 64-bit type. Concerning cases like non-gcc MIPS, I'll mostly echo Tom's comments. I'm comfortable with the project saying "We've added atomics for the architectures we have. Help us with the rest!" It's reasonable to introduce an improvement that entails architecture-dependent code without requiring that the initial patch and initial author address every interesting target. The bar to restore "support", even years later, will be pretty low. In that light, I don't favor ripping out longstanding architecture-specific code for borderline platforms. Doing so raises the bar for restoring support, without proximate benefit.  http://www.postgresql.org/message-id/4694.1381676...@sss.pgh.pa.us -- Noah Misch EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers