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
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 |
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 |