Re: [ANNOUNCE] IMCS: In Memory Columnar Store for PostgreSQL

From: Jim Nasby <jim(at)nasby(dot)net>
To: knizhnik <knizhnik(at)garret(dot)ru>, Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, James Mansion <james(at)mansionfamily(dot)plus(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, David Fetter <david(at)fetter(dot)org>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [ANNOUNCE] IMCS: In Memory Columnar Store for PostgreSQL
Date: 2014-01-09 21:04:47
Message-ID: 52CF0EEF.2050408@nasby.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-announce pgsql-hackers

On 1/9/14, 1:18 PM, knizhnik wrote:
> So it is clear why do we need shared memory for parallel query execution. But why it has to be dynamic? Why it can not be preallocated at start time as most of other resources used by PostgreSQL?

That would limit us to doing something like allocating a fixed maximum of parallel processes (which might be workable) and only allocating a very small amount of memory for IPC. Small as in can only handle a small number of tuples. That sounds like a really inefficient way to shuffle data to and from parallel processes, especially because one or both sides would probably have to actually copy the data if we're doing it that way.

With DSM if you want to do something like a parallel sort each process can put their results into memory that the parent process can directly access.

Of course the other enormous win for DSM is it's the foundation for finally being able to resize things without a restart. For large dollar sites that ability would be hugely beneficial.
--
Jim C. Nasby, Data Architect jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net

In response to

Browse pgsql-announce by date

  From Date Subject
Next Message Robert Haas 2014-01-10 18:23:21 Re: [ANNOUNCE] IMCS: In Memory Columnar Store for PostgreSQL
Previous Message knizhnik 2014-01-09 20:18:51 Re: [ANNOUNCE] IMCS: In Memory Columnar Store for PostgreSQL

Browse pgsql-hackers by date

  From Date Subject
Next Message Steeve Lennmark 2014-01-09 21:10:20 Re: [PATCH] Relocation of tablespaces in pg_basebackup
Previous Message Greg Stark 2014-01-09 20:58:01 Re: Planning time in explain/explain analyze