On Fri, Apr 7, 2017 at 5:21 PM, Thomas Munro <thomas.mu...@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
shared-record-typmod-registry-v2.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
