Are we still interested in the master-slave scan patch
I may have some free time recently to work on the master-slave scan idea.
I've been able to support AS-IS both SeqScan and IndexScan. Are we still
interested in getting it into 8.2?
There are still some problems I am not quite sure the solution. One is the
Xid assignment -- we need this to assure that master and slaves see the same
snapshot. The other is the connection pool architecture: shall we let
postmaster manage the slaves or let another process say slave-master to
handle them? Currently I am choosing the latter.
Regards,
Qingqing
QingQing,
I may have some free time recently to work on the master-slave scan idea.
I've been able to support AS-IS both SeqScan and IndexScan. Are we still
interested in getting it into 8.2?
I don't know about anyone else, but *I'm* still interested.
There are still some problems I am not quite sure the solution. One is the
Xid assignment -- we need this to assure that master and slaves see the
same snapshot. The other is the connection pool architecture: shall we let
postmaster manage the slaves or let another process say slave-master to
handle them? Currently I am choosing the latter.
Hmmm. Why not the postmaster?
--
Josh Berkus
PostgreSQL @ Sun
San Francisco
"Josh Berkus" <josh@agliodbs.com> wrote
The other is the connection pool architecture: shall we let
postmaster manage the slaves or let another process say slave-master to
handle them? Currently I am choosing the latter.Hmmm. Why not the postmaster?
Not real reason just feel that's clearer (but indeed it caused some
trouble). I am thinking maybe we should make a server-side connection pool
patch as a first step (which was discussed long time ago but no conclusion
yet). In this way, we will be able to reduce the connection time and make a
basis for parallel execution.
Regards,
Qingqing