On Thu, Jul 17, 2014 at 4:45 AM, Thor Lancelot Simon <t...@panix.com> wrote: > Except, of course, for IEEE floating point, because the VAX's floating point > unit simply does not provide that
Actually I think that's relevant. We usually get focused on the concurrency because that's an area where architectures vary a lot but it sounds like VAX barely supports multiple CPUs and generally older architectures had fairly mundane concurrency semantics since they were designed to work with existing toolchains. From memory it wasn't until later Sparc chips and Alpha that people started to experiment with looser concurrency models and expecting the toolchains to satisfy complex constraints to make them work. But imho the interesting thing about supporting some older architectures is for things like smoking out assumptions that math is IEEE floating point or whatever caused initdb to generate an initial config that couldn't start due to requiring too much memory. There could also be interesting(ish) performance losses if we're using lots of floating point math on a machine where floating point is emulated or perhaps using lots of 64-bit integers on a machine where it's implemented by the compiler using 32-bit operations. I don't think we're too concerned about performance on older architectures but if it's easy enough to avoid we might want to. Or at least we might want to know what architectures can't reasonably run a database due to these kinds of issues. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
