From: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
---|---|
To: | Jon Cruz <JoCruz(at)ncen(dot)com> |
Cc: | "A(dot) Kretschmer" <andreas(dot)kretschmer(at)schollglas(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Limitations : Number of ... |
Date: | 2006-02-23 19:55:27 |
Message-ID: | 20060223195527.GK28530@svana.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thu, Feb 23, 2006 at 11:21:33AM -0800, Jon Cruz wrote:
>
>
> Thanks. Yeah, I actually *did* do a search of the archives, as well as
> Google, but I'm only finding the size limitations (and everything else).
>
> I'm looking for the number of actual tables a server can handle. And
> the number of databases.
>
> My gut feeling is "unlimited" (like everything else)...
Logically, unlimited. Practically, because tables are stored as files,
at some point you might run out of inodes on your disk. You're more
likely to run out of disk-space first though, unless your tables are
small.
More directly, as the number of tables grow, so does the size of the
system catalogs. So this will show up as increased planning time.
Databases are just a way of dividing up tables. No strict limit, but
the number-of-files thing applies.
Actually, it's tables-per-database that's the relevent to planning
time, as the backend doesn't need to worry about tables in other
databases.
Hope this helps,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.
From | Date | Subject | |
---|---|---|---|
Next Message | Brandon Metcalf | 2006-02-23 19:55:34 | subtracting minutes from date |
Previous Message | Mike G. | 2006-02-23 19:23:14 | pg_autovacuum on Windows triggers string warning |