Re: removing old ports and architectures

On 2013-10-13 16:56:12 +0200, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> > That's a fair point. But all of them will use gcc, right? I've
> > previously thought we'd need 4.4 because there's an incompatibility
> > between 4.3 and 4.4 but I think it won't touch us, so 4.2 which added
> > atomics for mips seems fine. Given there's no buildfarm animal and
> > there's lots of variety out there that seems like a fair amount of
> > support.

> FWIW, I wouldn't have the slightest bit of difficulty with setting a
> project policy that if you want some platform to be supported, you
> must provide a buildfarm animal running on it.

> More to the point for this specific case, it seems like our process
> ought to be
> (1) select a preferably-small set of gcc atomic intrinsics that we
> want to use.
> (2) provide macro wrappers for these so that substituting other
> implementations isn't too tough.
> (3) for any platform where people don't want to use recent gcc,
> insist they provide substitute implementations of the macros.
>
> I don't think the core project has to be responsible for implementing
> (3), except maybe on very-mainstream arches such as x86. We can
> adopt a self-help attitude for everything else.

Sounds fair to me.

The question about platforms that simply cannot provide such atomics
like PA-RISC, which afaics is the only one, remains tho. I am not sure
we really want to provide codepaths that are only going to be tested
there.

I do plan to propose a set of macros for this once we know what cases we
need to support.

> But ... having said all that, it would be nice to see some proof of
> significant performance benefits that we're going to get from kicking
> those non-mainstream arches to the curb. I'm not enamored of removing
> real functionality now for vague promises of benefits later.

The reason I am bringing this up is that I'd like lift the patch in
http://archives.postgresql.org/message-id/20130926225545.GB26663%40awork2.anarazel.de
from a purely POC state to something committable. The numbers in it seem
to justify causing some pain.
Once the infrastructure is there we can easily get some really nice
further benefits by changing buffer pinning - that's one of the most
expensive things wrt. scalability after the above patch.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services