Re: POC: Sharing record typmods between backends
Thomas Munro <thomas.munro@enterprisedb.com>
Attachments
- shared-record-typmod-registry-v2.patch (application/octet-stream) patch v2
On Fri, Apr 7, 2017 at 5:21 PM, Thomas Munro <thomas.munro@enterprisedb.com> wrote: > * It would be nice for the SharedRecordTypeRegistry to be able to > survive longer than a single parallel query, perhaps in a per-session > DSM segment. Perhaps eventually we will want to consider a > query-scoped area, a transaction-scoped area and a session-scoped > area? I didn't investigate that for this POC. This seems like the right way to go. I think there should be one extra patch in this patch stack, to create a per-session DSA area (and perhaps a "SharedSessionState" struct?) that worker backends can attach to. It could be created when you first run a parallel query, and then reused for all parallel queries for the rest of your session. So, after you've run one parallel query, all future record typmod registrations would get pushed (write-through style) into shmem, for use by other backends that you might start in future parallel queries. That will avoid having to copy the leader's registered record typmods into shmem for every query going forward (the behaviour of the current POC patch). > * Perhaps simplehash + an LWLock would be better than dht, but I > haven't looked into that. Can it be convinced to work in DSA memory > and to grow on demand? Any views on this? > 1. Apply dht-v3.patch[3]. > 2. Apply shared-record-typmod-registry-v1.patch. > 3. Apply rip-out-tqueue-remapping-v1.patch. Here's a rebased version of the second patch (the other two still apply). It's still POC code only and still uses a per-parallel-context DSA area for space, not the per-session one I am now proposing we develop, if people are in favour of the approach. In case it wasn't clear from my earlier description, a nice side effect of using a shared typmod registry is that you can delete 85% of tqueue.c (see patch #3), so if you don't count the hash table implementation we come out about even in terms of lines of code. -- Thomas Munro http://www.enterprisedb.com
Commits
-
Remove TupleDesc remapping logic from tqueue.c.
- 6b65a7fe62e1 11.0 landed
-
Add support for coordinating record typmods among parallel workers.
- cc5f81366c36 11.0 landed
-
Improve division of labor between execParallel.c and nodeGather[Merge].c.
- 51daa7bdb39e 11.0 cited
-
Add minimal regression test for blessed record type transfer.
- d36f7efb39e1 11.0 landed
-
Consolidate the function pointer types used by dshash.c.
- d7694fc14870 11.0 landed
-
Fix unlikely shared memory leak after failure in dshash_create().
- 4569715bd6fa 11.0 landed
-
Refactor typcache.c's record typmod hash table.
- 35ea75632a56 11.0 landed
-
Add a hash_combine function for mixing hash values.
- 0052a0243d9c 11.0 landed
-
Backpatch introduction of TupleDescAttr(tupdesc, i).
- 8cda1fadd25b 9.2.23 landed
- 5b286cae3cc1 9.3.19 landed
- 3d58994eccb7 9.4.14 landed
- d778a77d38be 9.5.9 landed
- 6c036d01089c 9.6.5 landed
- d34a74dd064a 10.0 landed
-
Partially flatten struct tupleDesc so that it can be used in DSM.
- c6293249dc17 11.0 landed
-
Change tupledesc->attrs[n] to TupleDescAttr(tupledesc, n).
- 2cd708452400 11.0 landed