-----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-----
