Re: Support Parallel Query Execution in Executor
От | Tom Lane |
---|---|
Тема | Re: Support Parallel Query Execution in Executor |
Дата | |
Msg-id | 20531.1144478989@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Support Parallel Query Execution in Executor (Josh Berkus <josh@agliodbs.com>) |
Ответы |
Re: Support Parallel Query Execution in Executor
|
Список | pgsql-hackers |
Josh Berkus <josh@agliodbs.com> writes: > Basically reading a large table off disk does this: > read some table while not processing > process in cpu while not reading > read some more table while not processing > process some more in cpu while not reading > etc. > resulting in an I/O througput graph that looks like: > * * * > * * * * * * > * * * * * * > * * * * Interesting ... > The really annoying part about this, for me personally, is that the peaks > are significantly faster than comparable commercial DBMSes ... but our > average is far less. So even on a single seq scan, parallel query > execution would make a significant difference in performance, possibly as > much as +75% on seq scans of large tables. ... but I'm failing to follow where it says that parallel processing will fix that. All I can foresee in that direction is extra data transfer costs, bought at the price of portability and locking headaches. regards, tom lane
В списке pgsql-hackers по дате отправления: