Re: Hash tables in dynamic shared memory - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Hash tables in dynamic shared memory
Date
Msg-id CAEepm=1XabWyU685Ub84R6mQUeqpMn1a2q6UvjCa=jb3pZy87w@mail.gmail.com
Whole thread Raw
In response to Re: Hash tables in dynamic shared memory  (Andres Freund <andres@anarazel.de>)
Responses Re: Hash tables in dynamic shared memory
List pgsql-hackers
On Wed, Oct 5, 2016 at 11:22 AM, Andres Freund <andres@anarazel.de> wrote:
>> Potential use cases for DHT include caches, in-memory database objects
>> and working state for parallel execution.
>
> Is there a more concrete example, i.e. a user we'd convert to this at
> the same time as introducing this hashtable?

A colleague of mine will shortly post a concrete patch to teach an
existing executor node how to be parallel aware, using DHT.  I'll let
him explain.

I haven't looked into whether it would make sense to convert any
existing shmem dynahash hash table to use DHT.  The reason for doing
so would be to move it out to DSM segments and enable dynamically
growing.  I suspect that the bounded size of things like the hash
tables involved in (for example) predicate locking is considered a
feature, not a bug, so any such cluster-lifetime core-infrastructure
hash table would not be a candidate.  More likely candidates would be
ephemeral data used by the executor, as in the above-mentioned patch,
and long lived caches of dynamic size owned by core code or
extensions.  Like a shared query plan cache, if anyone can figure out
the invalidation magic required.

-- 
Thomas Munro
http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Idea: Tell compiler palloc() et al return aligned values
Next
From: Thomas Munro
Date:
Subject: Re: Hash tables in dynamic shared memory