| From: | Shaun Thomas <sthomas(at)optionshouse(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: Slow query when used in a view |
| Date: | 2013-03-12 13:49:04 |
| Message-ID: | 513F3250.2050208@optionshouse.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On 03/11/2013 06:56 PM, Tom Lane wrote:
> And that means that you get the inefficient plan wherein the
> foo-to-tiny_foo join is computed in its entirety.
:(
That's unfortunate, though I guess it makes sense. I moved the join in
the view into the SELECT clause as an EXISTS, and that seems to work
without major adverse effects. Apparently the tiny table really will be
tiny in actual use, so impact should be minimal.
I just really don't like using subselects that way. :)
Thanks, Tom!
--
Shaun Thomas
OptionsHouse | 141 W. Jackson Blvd. | Suite 500 | Chicago IL, 60604
312-676-8870
sthomas(at)optionshouse(dot)com
______________________________________________
See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Misa Simic | 2013-03-12 14:13:06 | Re: Slow concurrent processing |
| Previous Message | Victor Yegorov | 2013-03-12 13:36:54 | Re: Large Table - Slow Window Functions (Better Approach?) |