From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Віталій Тимчишин <tivv00(at)gmail(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Exists, limit and alternate plans |
Date: | 2010-07-12 14:45:14 |
Message-ID: | 15039.1278945914@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
=?KOI8-U?B?96bUwcymyiD0yc3eydvJzg==?= <tivv00(at)gmail(dot)com> writes:
> So, my Qs:
> 1) Do we really have alternative plans for SubPlan that are selected at
> runtime? Wow.
Yup, see the AlternativeSubPlan stuff.
> 2) Why "Seq scan" plan is selected by default? Is it because of outer limit
> not being applied when calculating costs for subplans at runtime?
It's currently driven off the estimated rowcount for the parent plan
node --- 6831169 in your example. The subplan cannot see that the
parent plan node will be terminated short of full execution, so it
thinks that hashing the whole investor table will be a win.
Obviously it'd be nice to improve that for cases like upper LIMITs.
> 3) Why does limit inside exists helps?
I think it defeats the applicability of the hash-the-whole-subtable
approach.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2010-07-12 15:23:16 | Re: performance on new linux box |
Previous Message | Віталій Тимчишин | 2010-07-12 13:29:07 | Exists, limit and alternate plans |