Re: Parallel Seq Scan
От | Robert Haas |
---|---|
Тема | Re: Parallel Seq Scan |
Дата | |
Msg-id | CA+TgmoZHoiFki0prU0ECMFkyiw7WAAZfi-TK1dMCBDjg_WuiZg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Parallel Seq Scan (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: Parallel Seq Scan
|
Список | pgsql-hackers |
On Fri, Sep 25, 2015 at 7:46 AM, Amit Kapila <amit.kapila16@gmail.com> wrote: > I have a question here which is why this format doesn't have a similar > problem > as the current version, basically in current patch the second read of > SerializedParamExternData can be misaligned and for same reason in your > patch the second read of Oid could by misaligned? memcpy() can cope with unaligned data; structure member assignment can't. I've worked some of this code over fairly heavily today and I'm pretty happy with how my copy of execParallel.c looks now, but I've run into one issue where I wanted to check with you. There are three places where Instrumentation can be attached to a query: a ResultRelInfo's ri_TrigInstrument (which doesn't matter for us because we don't support parallel write queries, and triggers don't run on reads), a PlanState's instrument, and a QueryDesc's total time. Your patch makes provision to copy ONE Instrumentation structure per worker back to the parallel leader. I assumed this must be the QueryDesc's totaltime, but it looks like it's actually the PlanState of the top node passed to the worker. That's of course no good if we ever push more than one node down to the worker, which we may very well want to do in the initial version, and surely want to do eventually. We can't just deal with the top node and forget all the others. Is that really what's happening here, or am I confused? Assuming I'm not confused, I'm planning to see about fixing this... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: