Thanks Tom. In the original plan a query of this sort was never supposed to happen, but it looks like some coding issues may have allowed it.
-----Original Message----- From: Tom Lane [mailto:t...@sss.pgh.pa.us] Sent: September-19-12 2:04 PM To: Michael Holt Cc: pgsql-admin@postgresql.org Subject: Re: [ADMIN] max_locks_per_transaction and partitioned tables Michael Holt <mh...@terapeak.com> writes: > We've had a system in operation for a few years that makes use of a > substantial amount of partitioning. The parent table now has over 4,000 > children tables. Within the last couple of days the server started giving > "out of shared memory" errors with the suggestion to increase the > max_locks_per_transaction. > If the parent table is queried will it require a lock for each one of the > child tables? I'm guessing it will. Yup, it will. I'm a bit astonished that you've gotten this far without horrid performance problems. The underlying mechanisms for inheritance aren't really designed to scale past perhaps a hundred child tables. regards, tom lane -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
