[pgpool-general: 3774] Re: deprecation of 'parallel query' feature

Alex Toth atoth at gravity.com
Tue Jun 2 03:17:36 JST 2015

You may be able to do what you want as far as connecting to the back 
ends, but it's probably not the best idea.  There are a couple different 
table partitioning models for partitioning (replication and round robin) 
distributed by either hash or modulo.  I can't swear, because I've never 
tried and I abandoned my test pg-xc cluster long ago, but perhaps using 
replication+modulo or just replication at a level so all tables are 
replicated to all backends, maybe.

Most likely you'd have to adjust your data load to use the front end 
rather than the back end.  I wouldn't be surprised if direct writes to 
the back ends would cause confusion in the front ends; they're more 
directly involved in data distribution and lookup than pgpool is.  I 
suggest you ask the postgres-xc and/or postgres-xl mailing lists because 
you'll find more expertise there than here.


On 5/27/15 08:36, Wim Nederend wrote:
> Hi Tatsuo,
> I understand. I'm looking at the comments Alex Toth made. I takes more 
> study to get it working, and I don't know yet
> whether one can connect to the backend nodes directly, like with 
> pgpool is possible.
> Do you have a rough estimate how long the 'parallel query' code will 
> be part of the package code?
> Regards, Wim
> On 05/22/2015 01:16 AM, Tatsuo Ishii wrote:
>> Unfortunately the development resource of pgpool-II is limited (this
>> is not uncommon in all open source projects). Also companies that are
>> helping the project do not have any customer who are using the
>> parallel query feature. So developers need to "triage" the priority.
>> Sorry for this.
>> Best regards,
>> -- 
>> Tatsuo Ishii
>> SRA OSS, Inc. Japan
>> English: http://www.sraoss.co.jp/index_en.php
>> Japanese:http://www.sraoss.co.jp
>>> Hi,
>>> Recently I read http://www.pgpool.net/docs/latest/pgpool-en.html
>>> There I read that the 'parallel query' feature will not be supported
>>> anymore in the future.
>>> I would appreciate reconsidering this decision, because I'm using the
>>> feature in my projects.
>>> I use it to have a geographical data base, partioned across a number
>>> (about 10) of database hosts.
>>> The data is accessed through python psycopg2.
>>> Some queries are done through the pgpool instance (some global
>>> searches and the final exports).
>>> Most operations (import, manipulations) however are done through
>>> connections directly to the backend hosts.
>>> So I don't mind whether performance through pgpool is not very high.
>>> I would appreciate the parallel query is still available in future
>>> versions.
>>> Regards, Wim Nederend
>>> _______________________________________________
>>> pgpool-general mailing list
>>> pgpool-general at pgpool.net
>>> http://www.pgpool.net/mailman/listinfo/pgpool-general
> _______________________________________________
> pgpool-general mailing list
> pgpool-general at pgpool.net
> http://www.pgpool.net/mailman/listinfo/pgpool-general

More information about the pgpool-general mailing list