Re: shared memory/max_locks_per_transaction error
От | Kynn Jones |
---|---|
Тема | Re: shared memory/max_locks_per_transaction error |
Дата | |
Msg-id | c2350ba40803170852l67c0a631i8b562f64f0045830@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: shared memory/max_locks_per_transaction error (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-general |
Tom, Alvaro:
Thank you much for the clarification. It's "back to the drawing board" for me!
Kynn
On Mon, Mar 17, 2008 at 10:55 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
"Kynn Jones" <kynnjo@gmail.com> writes:> I'm leaning towards the re-design option, primarily because I really don'tBecause the size of the lock table in shared memory has to be set at
> really understand the consequences of cranking up max_locks_per_transaction.
> E.g. Why is its default value 2^6, instead of, say, 2^15? In fact, why is
> there a ceiling on the number of locks at all?
postmaster start.
There are people running DBs with a couple hundred thousand tables,
but I don't know what sorts of performance problems they face when
they try to run pg_dump. I think most SQL experts would suggest
a redesign: if you have lots of essentially identical tables the
standard advice is to fold them all into one table with one more
key column.
regards, tom lane
В списке pgsql-general по дате отправления: