-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi,
First, thanks a lot for opening Postgres-R, I hope -core will find in your code as many good ideas and code as possible :)
Le 15 juil. 08 à 18:48, Markus Wanner a écrit :
A pretty general framework for helper processes is provided. I think this framework could be used for parallel querying or data loading as well. The helper processes are ordinary backends which process a single transaction at a time. But they don't have a client connection, instead they communicate with a manager via a messaging module based on shared memory and signals. Within Postgres-R, those helper backends are mostly called 'remote backends', which is a somewhat misleading name. It's just a short name for a helper backend which processes a remote transaction.
Could this framework help the current TODO item to have a concurrent pg_restore?
The ideas I remember of on this topic where to add the capability for pg_restore to create all indexes of any given table in parallel as to benefit from concurrent seqscan improvements of 8.3.
There was also the idea to have pg_restore handle the ALTER TABLE statements in parallel to the other data copying taking place, this part maybe requiring more dependancy information than currently available.
And there was some parallel pg_dump idea floating around too, in order to give PostgreSQL the capability to saturate high-end hardware at pg_dump time, as far as I understood this part of the mails.
Of course, reading that an Open Source framework for parallel queries in PostgreSQL is available, can we skip asking if having the executor benefit from it for general purpose queries would be doable?
Regards, - -- dim -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkh+UjwACgkQlBXRlnbh1bmsAwCaAhr4xTeCeGjtuap4sHL04IOP OL8AoI0yv0qEn1eDt+s0qeajzxyIqRhI =KaLQ -----END PGP SIGNATURE----- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
