| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Aidan Van Dyk <aidan(at)highrise(dot)ca>, pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com> |
| Subject: | Re: Latches with weak memory ordering (Re: max_wal_senders must die) |
| Date: | 2010-11-19 14:54:58 |
| Message-ID: | AANLkTin8A3NJD47idGqP3Dtj1_e6oyiUceBUHErbtXra@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Nov 19, 2010 at 9:51 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> On Friday 19 November 2010 15:49:45 Robert Haas wrote:
>> If we're going to work on memory primitives, I would much rather see
>> us put that effort into, say, implementing more efficient LWLock
>> algorithms to solve the bottlenecks that the MOSBENCH guys found,
>> rather than spending it on trying to avoid a minor API complication
>> for the latch facility.
> But for that you will need more infrastructure in that area anyway.
True, but you don't have to do it all at once. You can continue to do
the same old stuff on the platforms you currently support, and use the
newer stuff on platforms where the right thing to do is readily
apparent, like x64 and x86_64. And people can add support for their
favorite platforms gradually over time, rather than having a flag day
where we stop supporting everything we don't know what to do with.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Shigeru HANADA | 2010-11-19 14:55:15 | Re: SQL/MED estimated time of arrival? |
| Previous Message | Andres Freund | 2010-11-19 14:51:17 | Re: Latches with weak memory ordering (Re: max_wal_senders must die) |