From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | josh(at)agliodbs(dot)com |
Cc: | pgsql-hackers(at)postgresql(dot)org, "Mike Rylander" <mrylander(at)gmail(dot)com>, "Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu> |
Subject: | Re: Support Parallel Query Execution in Executor |
Date: | 2006-04-08 06:49:49 |
Message-ID: | 20531.1144478989@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Josh Berkus <josh(at)agliodbs(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Philipp Ott | 2006-04-08 12:04:28 | Re: Postgres Library natively available for Mac OSX Intel? |
Previous Message | Hans-Jürgen Schönig | 2006-04-08 06:25:25 | Re: Tru64/Alpha problems |
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2006-04-08 10:40:35 | Re: Bug in window xp |
Previous Message | Robert Treat | 2006-04-08 02:35:30 | Re: [HACKERS] please actualize FAQ, broken urls |