Thread: Limitations : Number of ...

Limitations : Number of ...

From
"Jon Cruz"
Date:

Two quick questions :

 

What is the max number of databases on a PostgreSQL server?

What is the max number of tables in a database ?

 

Thanks

 

Jon D Cruz

 

Re: Limitations : Number of ...

From
"A. Kretschmer"
Date:
am  23.02.2006, um 10:00:01 -0800 mailte Jon Cruz folgendes:
> Two quick questions :
>
> What is the max number of databases on a PostgreSQL server?
> What is the max number of tables in a database ?


Please, read our FAQ.
http://www.postgresql.org/docs/faqs.FAQ.html

And yes: we don't have limitations ;-)



Andreas
--
Andreas Kretschmer    (Kontakt: siehe Header)
Heynitz:  035242/47215,      D1: 0160/7141639
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
 ===    Schollglas Unternehmensgruppe    ===

Re: Limitations : Number of ...

From
"Jon Cruz"
Date:

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)...


Jon D Cruz


-----Original Message-----
From: pgsql-general-owner@postgresql.org
[mailto:pgsql-general-owner@postgresql.org] On Behalf Of A. Kretschmer
Sent: Thursday, February 23, 2006 10:15 AM
To: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Limitations : Number of ...
Importance: High

am  23.02.2006, um 10:00:01 -0800 mailte Jon Cruz folgendes:
> Two quick questions :
>
> What is the max number of databases on a PostgreSQL server?
> What is the max number of tables in a database ?


Please, read our FAQ.
http://www.postgresql.org/docs/faqs.FAQ.html

And yes: we don't have limitations ;-)



Andreas
--
Andreas Kretschmer    (Kontakt: siehe Header)
Heynitz:  035242/47215,      D1: 0160/7141639
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
 ===    Schollglas Unternehmensgruppe    ===

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not
       match


Re: Limitations : Number of ...

From
Martijn van Oosterhout
Date:
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@svana.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.

Attachment

Re: Limitations : Number of ...

From
Tom Lane
Date:
Martijn van Oosterhout <kleptog@svana.org> writes:
> 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.

Another constraint is that many filesystems don't behave real well with
lots and lots of files in a single filesystem directory (where "lots and
lots" usually translates to trouble in the 10K-100K range).  You could
work around this to some extent by splitting the database into multiple
tablespaces, but most people are going to tell you that a schema with
that many tables needs reconsideration anyway.

            regards, tom lane