On Mon, Jun 14, 2010 at 01:06:04PM -0400, Michael Bayer wrote: > you can do the multi-schema thing using either a PoolListener, or a > Table subclass that implements a @property for the "schema" attribute > - in both cases these would be linked to a thread local variable that > you would set per request. If the load per site is low, you can also > forego the usage of pooling to eliminate the issue of dormant > connections (possibly look into something like pgpool, perhaps they > have some feature that optimizes this use case).
Both approach would work. The PoolListener looks a bit better, the Table subclass looks a bit hackish. BTW I am not planning to use threads, I'll just use a dozen python processes to make sure the site is responsive under heavy load. This should simplify pooling quite a bit, I'll just use a StaticPool. > As far as approach, consider the load each per-user site will have, > and how you might scale out to include multiple database servers. > I'd grep around the PG docs and wiki carefully to get a full grasp of > the implications of each approach. Yes, scaling was one of the motivation for this approach, I definitely need to learn more about how PG would handle this. Simplifying the architecture was the main motivation. I don't want to have a column `site_id` in every table. Also I think that putting everything in its own schema would improve performance dramatically: instead of big indexes for all sites, there'll be small indexes for each site. Thank-you so much, your reply helped a great deal. -- Henry Prêcheur -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
