From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Ken Geis <kgeis(at)speakeasy(dot)org> |
Cc: | Richard Huxton <dev(at)archonet(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: plan problem |
Date: | 2004-04-09 16:50:35 |
Message-ID: | 26675.1081529435@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Ken Geis <kgeis(at)speakeasy(dot)org> writes:
> Does anyone think that the planner issue has merit to address? Can
> someone help me figure out what code I would look at?
The planner doesn't currently attempt to "drill down" into a sub-select-
in-FROM to find statistics about the variables emitted by the sub-select.
So it's just falling back to a default estimate of the number of
distinct values coming out of the sub-select.
The "drilling down" part is not hard; the difficulty comes from trying
to figure out whether and how the stats from the underlying column would
need to be adjusted for the behavior of the sub-select itself. As an
example, the result of (SELECT DISTINCT foo FROM bar) would usually have
much different stats from the raw bar.foo column. In your example, the
LIMIT clause potentially affects the stats by reducing the number of
distinct values.
Now in most situations where the sub-select wouldn't change the stats,
there's no issue anyway because the planner will flatten the sub-select
into the main query. So we really have to figure out the adjustment
part before we can think about doing much here.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Patrick Hatcher | 2004-04-09 17:18:12 | Upgrading question (recycled transaction log) |
Previous Message | Andrew Matthews | 2004-04-09 16:12:38 | Re: Wierd issues |