Re: PostgreSQL for VAX on NetBSD/OpenBSD

From: Greg Stark <stark(at)mit(dot)edu>
To: Thor Lancelot Simon <tls(at)panix(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, John Klos <john(at)ziaspace(dot)com>, port-vax(at)netbsd(dot)org, vax(at)openbsd(dot)org, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PostgreSQL for VAX on NetBSD/OpenBSD
Date: 2014-07-17 14:53:30
Message-ID: CAM-w4HPvMberYJ5vGu3x=_Yhh1YN4+ROAuOn_XXQyCV4uUou3w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jul 17, 2014 at 4:45 AM, Thor Lancelot Simon <tls(at)panix(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2014-07-17 15:02:27 Re: [v9.5] Custom Plan API
Previous Message Alvaro Herrera 2014-07-17 14:47:04 Re: BUFFER_LOCK_EXCLUSIVE is used in ginbuildempty().