Re: Limitations : Number of ...

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.

In response to

Responses

Browse pgsql-general by date

  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