From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | removing old ports and architectures |
Date: | 2013-10-13 00:46:58 |
Message-ID: | 20131013004658.GG4056218@alap2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
As discussed in 20130926225545(dot)GB26663(at)awork2(dot)anarazel(dot)de and on quite
some other occasions there's quite some scalability improvements we
could make if we had cross platform support for atomic
operations. Providing that is a fair bit of work for every
architecture/compiler/OS, so I think it's a reasonable thing to remove
unused things first.
Alternatively we can maintain parallel code paths for atomic ops
supporting platforms and for those without, but that seems like a bad
idea from a complexity and testing perspective given that all even
remotely current platforms should support them.
I think we should remove support the following ports:
- IRIX
- UnixWare
- Tru64
Neither of those are relevant.
I think we should remove support for the following architectures:
- VAX
- univel (s_lock support remaining)
- sinix (s_lock support remaining)
- sun3 (I think it's just s_lock support remaining)
- natsemi 32k
- superH
- ALPHA (big pain in the ass to get right, nobody uses it anymore)
- m86k (doesn't have a useable CAS on later iterations like coldfire)
- M32R (no userspace CAS afaics)
- mips for anything but gcc > 4.4, using gcc's atomics support
- s390 for anything but gcc > 4.4, using gcc's atomics support
- 32bit/<v9 sparc (doesn't have proper atomics, old)
Possibly:
- all mips
- PA-RISC. I think Tom was the remaining user there? Maybe just !gcc.
Any arguments against?
Last round of discussion of removing dead ports:
1335292179(dot)13481(dot)4(dot)camel(at)vanquo(dot)pezone(dot)net
Discusses state of of spinlocks and barriers on various platforms:
20130920151110(dot)GA8508(at)awork2(dot)anarazel(dot)de
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2013-10-13 01:01:14 | Re: Re: custom hash-based COUNT(DISTINCT) aggregate - unexpectedly high memory consumption |
Previous Message | Kohei KaiGai | 2013-10-12 20:53:06 | Re: background workers, round three |