| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Carson, Leonard" <lcarson(at)sdsc(dot)edu> |
| Cc: | "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: views much slower in 9.3 than 8.4 |
| Date: | 2015-03-19 23:04:22 |
| Message-ID: | 13022.1426806262@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
"Carson, Leonard" <lcarson(at)sdsc(dot)edu> writes:
> Here are the 3 views and some timing notes:
> http://pgsql.privatepaste.com/decae31693#
That doesn't really leave us any wiser than before, unfortunately.
It's clear that the root of the problem is the drastic underestimation of
the size of the rq/a join, but it's not clear why that's happening, nor
why 8.4 would not have fallen into the same trap.
Would it be possible to provide the data in the join columns involved in
that part of the query? To wit
requests.account_id
requests.start_date
allocations.account_id
allocations.initial_start_date
allocations.resource_id
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Vladimir Borodin | 2015-03-20 15:00:16 | Re: [pgadmin-support] Issue with a hanging apply process on the replica db after vacuum works on primary |
| Previous Message | Joao Junior | 2015-03-19 19:40:46 | Re: Very slow checkpoints |