Re: performance config help
От
Dusek, Bob
Тема
Re: performance config help
Дата
Msg-id
6EB5F166D3FA6B499A1A25856BDB9B6085F4A482@susday216.corp.ncr.com
Ответ на
Re: performance config help (Kevin Grittner)
Список
Дерево обсуждения
performance config help Bob Dusek <redusek@gmail.com>
Re: performance config help "A. Kretschmer" <andreas.kretschmer@schollglas.com>
Re: performance config help Bob Dusek <redusek@gmail.com>
Re: performance config help Scott Marlowe <scott.marlowe@gmail.com>
Re: performance config help Bob Dusek <redusek@gmail.com>
Re: performance config help "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
Re: performance config help Bob Dusek <redusek@gmail.com>
Re: performance config help Scott Marlowe <scott.marlowe@gmail.com>
Re: performance config help Scott Marlowe <scott.marlowe@gmail.com>
Re: performance config help Bob Dusek <redusek@gmail.com>
Re: performance config help Scott Marlowe <scott.marlowe@gmail.com>
Re: performance config help Greg Smith <greg@2ndquadrant.com>
Re: performance config help Scott Marlowe <scott.marlowe@gmail.com>
Re: performance config help Greg Smith <greg@2ndquadrant.com>
Re: performance config help Scott Marlowe <scott.marlowe@gmail.com>
Re: performance config help Scott Marlowe <scott.marlowe@gmail.com>
Re: performance config help Ivan Voras <ivoras@freebsd.org>
Re: performance config help Bob Dusek <redusek@gmail.com>
Re: performance config help Pierre Frédéric Caillaud<lists@peufeu.com>
Re: performance config help Ivan Voras <ivoras@freebsd.org>
> > How do I learn more about the actual lock contention in my db? > > Lock contention makes some sense. Each of the 256 requests are > > relatively similar. So, I don't doubt that lock contention could > > be an issue. I just don't know how to observe it or correct it. > > It seems like if we have processes that are contending for locks, > > there's not much we can do about it. > > I'm not sure what the best way would be to measure it, but in prior > discussions the general mood seemed to be that if you had so many > active sessions that you were running into the issue, the best > solution was to use a connection pool to avoid it. Sorry.. by "not much we can do about it", I meant, from a query perspective. I mean, we can't use locking hints or anything like that in Postgres that I know of. I do understand that the connection pool will help this. > > -Kevin > > -- > Sent via pgsql-performance mailing list > (pgsql-performance@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-performance >
В списке pgsql-performance по дате отправления