From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Re: [COMMITTERS] Can not create more than 32766 databases in ufs file system. |
Date: | 2009-09-14 17:14:40 |
Message-ID: | 4AAE7A00.3010109@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
>> So the question I would ask goes more like "do you really need 32K
>> databases in one installation? Have you considered using schemas
>> instead?" Databases are, by design, pretty heavyweight objects.
>
> I agree, but at the same time, we might: a) update our documentation to
> indicate it depends on the filesystem, and b) consider how we might
> work around this limit (and if we feel the effort to be worth it).
I don't feel it's worth the effort.
I can think of lots of hosted application configurations where one might
need 33K tables. Note that PostgreSQL *already* handles this better
than Oracle or MySQL do -- I know at least one case where our ability to
handle large numbers of tables was a reason for migration from Oracle to
PostgreSQL.
However, I can think of no legitimate reason to need 33K active
databases in a single instance. I think someone has confused databases
with schema ... or even with tables. Filemaker developer, maybe? Or
maybe it 10 active databases and 32.99K archive ones ... in which case
they should be dumped to compressed backup and dropped.
--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-09-15 02:31:15 | pgsql: Fix possible buffer overrun and/or unportable behavior in |
Previous Message | Peter Eisentraut | 2009-09-14 13:23:48 | pgsql: Print builds don't actually depend on html target (anymore). |
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2009-09-14 17:29:58 | Re: Timestamp to time_t |
Previous Message | Kevin Grittner | 2009-09-14 17:12:38 | Re: Streaming Replication patch for CommitFest 2009-09 |