From: | Christopher Browne <cbbrowne(at)gmail(dot)com> |
---|---|
To: | Josh berkus <josh(at)agliodbs(dot)com> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>, PostgreSQL Mailing Lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Academic help for Postgres |
Date: | 2016-05-11 17:45:22 |
Message-ID: | CAFNqd5Uqo+ROKujEa584SRovOibOVy59DzbrEEEAYCfVGNXqMQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 11 May 2016 at 12:58, Josh berkus <josh(at)agliodbs(dot)com> wrote:
> Together with that, automated substitution of materialized views for
> query clauses.
>
> Also: optimizing for new hardware, like persistent memory.
I recently saw some material in ACM SIGOPS on tuning filesystems to play
better with some of the new sorts of storage
An interesting such article was thus... <
http://dl.acm.org/citation.cfm?id=2819002> The idea of it was to research
better ways of doing hash table updates with PCM (Phase Change Memory)
which apparently may be up-and-coming but with fairly different write
characteristics than we're used to. You essentially write a fairly large
page at a time, and can only do limited numbers of updates to any given
page.
That encourages things like log-structured filesystems, but with further
efforts to reduce there being "hot spots."
The paper was focused on hash tables; if the hardware turns out to be
important, it'll also be important to have better variations on B-trees.
--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2016-05-11 17:48:34 | Re: Re: Need help debugging why autovacuum seems "stuck" -- until I use superuser to vacuum freeze pg_database |
Previous Message | Robert Haas | 2016-05-11 17:38:33 | Re: parallel.c is not marked as test covered |