From: | Mark Roberts <mailing_lists(at)pandapocket(dot)com> |
---|---|
To: | |
Cc: | pgsql-general General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: limits? |
Date: | 2008-06-23 19:14:14 |
Message-ID: | 1214248454.25936.24.camel@localhost |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Mon, 2008-06-23 at 11:21 -0700, Steve Atkins wrote:
>
>
> http://www.postgresql.org/about/ has some of the theoretical limits.
>
> In real use you're unlikely to hit any limits, theoretical or
> practical, but if you start to use a silly number of tables and so
> on
> you're likely to hit performance issues eventually. I'm not sure
> where
> that threshold would be, but it's higher than "thousands".
>
> Cheers,
> Steve
I'm just a developer (my DBA would have more details on the settings
that needed adjusting), but I will attest to it being reasonably easy to
hit database limits.
For us, it was related to having a reasonably small number of (large)
aggregate tables that are partitioned (inherited with check constraints)
by week.
The real problem wasn't the absolute limit of tables (IIRC) as much as
accessing the data in a parallel manner from the parent tables in bulk
update transactions (the parallel was probably what pushed it over the
top).
The limit is absurdly high, and by the time you hit it, you'll probably
have a really good idea of how to overcome it. Really, there's lots of
"challenges" you'll overcome before that time (IMO).
Of course all this is anecdotal, and you should take it with a grain of
salt. :)
-Mark
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Marlowe | 2008-06-23 19:20:20 | Re: Details on community survey |
Previous Message | Tom Lane | 2008-06-23 19:00:05 | Re: Data Types |