| From: | Rod Taylor <pg(at)rbt(dot)ca> |
|---|---|
| To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
| Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, pgsql-hackers(at)postgresql(dot)org, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
| Subject: | Re: Call for 7.5 feature completion |
| Date: | 2005-08-26 01:26:58 |
| Message-ID: | 1125019618.36010.379.camel@home |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, 2005-08-25 at 21:27 -0400, Andrew Dunstan wrote:
>
> Rod Taylor wrote:
>
> > * Multi-CPU sorts. Take a large single sort like an index creation
> > and split the work among multiple CPUs.
> This really implies threading, doesn't it? And presumably it would have
> many possible uses besides this one for doing parallel work, e.g. maybe
> the planner could evaluate several alternative plans in parallel.
I don't think threading is needed.
I pictured PostgreSQL spawning one process per CPU explicitly for
sorting which standard backends could use as required to do batch work.
Not necessarily easy to do but it would sure be handy.
--
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2005-08-26 01:27:26 | Re: Call for 7.5 feature completion |
| Previous Message | Josh Berkus | 2005-08-26 00:59:33 | Welcome Core Team member Dave Page |