| From: | Rural Hunter <ruralhunter(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Very slow planning performance on partition table |
| Date: | 2014-07-28 01:18:59 |
| Message-ID: | 53D5A503.5060406@gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin pgsql-performance |
Yes I checked. The connection I inspected is the longest running one.
There was no other connections blocking it. And I also see all locks are
granted for it. Does the planning phase require some internal locks?
在 2014/7/28 0:28, Tom Lane 写道:
> Yeah, that's what the stack trace suggests. Have you looked into pg_locks
> and pg_stat_activity to see which lock it wants and what's holding said
> lock?
>
> regards, tom lane
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Rural Hunter | 2014-07-28 07:01:19 | Re: Very slow planning performance on partition table |
| Previous Message | Tom Lane | 2014-07-27 16:28:07 | Re: Very slow planning performance on partition table |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Craig Ringer | 2014-07-28 03:58:22 | Re: High rate of transaction failure with the Serializable Isolation Level |
| Previous Message | Vitalii Tymchyshyn | 2014-07-27 20:09:41 | Re: Cursor + upsert (astronomical data) |