Samuel Gendler wrote
> On Thu, Nov 8, 2012 at 1:36 AM, Denis <
> socsam@
> > wrote:
>
>>
>> P.S.
>> Not to start a holywar, but FYI: in a similar project where we used MySQL
>> now we have about 6000 DBs and everything works like a charm.
>>
>
> You seem to have answered your own question here. If my recollection of a
> previous discussion about many schemas and pg_dump performance is
> accurate,
> I suspect you are going to be told that you've got a data architecture
> that
> is fairly incompatible with postgresql's architecture and you've
> specifically ruled out a solution that would play to postgresql's
> strengths.
Ok guys, it was not my intention to hurt anyone's feelings by mentioning
MySQL. Sorry about that. There simply was a project with a similar
architecture built using MySQL. When we started the current project, I have
made a decision to give PostgreSQL a try. Now I see that the same
architecture is not applicable if PostgreSQL is used.
I would recommend you to refresh the info here
http://wiki.postgresql.org/wiki/FAQ. There is a question "What is the
maximum size for a row, a table, and a database?". Please add there info on
maximum DBs number and tables number one DB can contain while PostgreSQL
continues to work properly.
PS: the easiest solution in my case is to create initially 500 DBs (like
app_template_[0-500]) and create up to 500 schemas in each of it. This will
make 250000 possible clients in total. This should be enough. The question
is: can you see the possible pitfalls of this solution?
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Thousands-databases-or-schemas-tp5731189p5731203.html
Sent from the PostgreSQL - performance mailing list archive at Nabble.com.
