On Dec 1, 2007 9:42 AM, henk de wit <henk53602@hotmail.com> wrote:
> Wouldn't this offer some opportunities for running things on multiple cores?
No, it's not actually parallel in the same sense.
> Yes, I noticed this project before. At the time it was not really clear how
> stable and/or how well supported this is. It indeed seems to support
> parallel queries automatically by being able to rewrite standard queries. It
> does seem it needs different DB nodes and is thus probably not able to use
> multiple cores of a single DBMS.
I've seen it actually set up to use multiple connections to the same
DBMS. How well it would work is pretty much dependent on your
application and the amount of parallelization you could actually gain.
> Also, I could not really find how well
> pgpool-II is doing at making judgments of the level of parallelization it's
> going to use. E.g. when there are 16 nodes in the system with a currently
> low utilization, a single query may be split into 16 pieces. On the other
> hand, when 8 of these nodes are heavily utilized, splitting to 8 pieces
> might be better. etc.
IIRC, it doesn't plan parallelization that way. It looks at what is
partitioned (by default) on different nodes and parallelizes based on
that. As I said earlier, you can partition a single node and put
pgpool-II on top of it to gain some parallelization. Unfortunately,
it isn't capable of handling things like parallel index builds or
other useful maintenance features... but it can do fairly good query
result parallelization.
--
Jonah H. Harris, Sr. Software Architect | phone: 732.331.1324
EnterpriseDB Corporation | fax: 732.331.1301
499 Thornall Street, 2nd Floor | jonah.harris@enterprisedb.com
Edison, NJ 08837 | http://www.enterprisedb.com/