| From: | "Dusek, Bob" <rd185032(at)ncr(dot)com> |
|---|---|
| To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Bob Dusek <redusek(at)gmail(dot)com> |
| Cc: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: performance config help |
| Date: | 2010-01-11 22:06:24 |
| Message-ID: | 6EB5F166D3FA6B499A1A25856BDB9B6085F4A482@susday216.corp.ncr.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
> > 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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Smith | 2010-01-11 22:12:33 | Re: performance config help |
| Previous Message | Greg Smith | 2010-01-11 22:04:08 | Re: performance config help |