Re: Shared Memory hash tables only at startup

From: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
To: hariprasath nallasamy <hariprasathnallasamy(at)gmail(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Shared Memory hash tables only at startup
Date: 2017-05-02 22:54:24
Message-ID: CAEepm=2esteG76fevs8hU8=AVTrQ_O7rrqiJHKEUoRPV9fjNOQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, May 2, 2017 at 11:54 PM, hariprasath nallasamy
<hariprasathnallasamy(at)gmail(dot)com> wrote:
> Hi
> It is clear that all of the shared memory hash tables are created during
> startup using ShmemInitHash()
>
> (In practice, all creations are done in the postmaster
> process; child processes should always be attaching to existing tables.)
>
> Is there any specific reason to do so or my understanding was wrong(we can
> create shared memory hash table at run time too?)

Because we use processes and not threads, the space has to be
allocated up front and then inherited by other process in order to
inherit the same memory map so that raw pointers can be exchanged
between backends. DynaHash is a data structure made out of raw
pointers.

I have a proposal[1] that would provide dynamic concurrent hash tables
that can be created after startup using DSM/DSA memory, but then you
have to deal with kooky pointers, which falls out of Postgres's
policies of avoiding multithreading and embracing parallelism.

[1] https://www.postgresql.org/message-id/flat/CAEepm%3D3d8o8XdVwYT6O%3DbHKsKAM2pu2D6sV1S_%3D4d%2BjStVCE7w%40mail.gmail.com

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2017-05-02 23:00:38 Re: CTE inlining
Previous Message Alvaro Herrera 2017-05-02 21:52:15 Re: changing mvstats output to be valid JSON