Re: Exists, limit and alternate plans

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

In response to

Browse pgsql-performance by date

  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