Re: The science of optimization in practical terms?

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com>, decibel <decibel(at)decibel(dot)org>, Greg Smith <gsmith(at)gregsmith(dot)com>, jd(at)commandprompt(dot)com, Grzegorz Jaskiewicz <gj(at)pointblue(dot)com(dot)pl>, Bernd Helmle <mailings(at)oopsware(dot)de>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: The science of optimization in practical terms?
Date: 2009-02-18 20:50:28
Message-ID: 603c8f070902181250q7d88de9as479e5ea379733c94@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Feb 18, 2009 at 3:32 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> ... At any rate, we'd need to save quite
>> a bit to pay for carting around best and worst case costs for every
>> plan we consider.
>
> Another problem with this is it doesn't really do anything to solve the
> problem we were just discussing, namely having an intelligent way of
> combining inaccurate estimates for WHERE clauses. If you just take a
> range of plausible values and multiply then it doesn't take very many
> clauses to get to a range of [0,1] --- or at least a range of
> probabilities wide enough to be unhelpful.

Yeah.

> An idea that I think has been mentioned before is to try to identify
> cases where we can *prove* there is at most one row emitted by a
> sub-path (eg, because of a unique index, DISTINCT subplan, etc). Then
> we could penalize nestloops with outer relations that weren't provably a
> single row. This is basically restricting the notion of estimation
> confidence to a special case that's particularly important for SQL.

I thought about this, too, and I agree. Having this information
available would also be very helpful for join removal. I believe that
you did some work on this for SEMI/ANTI-join support in the form of
query_is_distinct_for, but I'm not sure if that takes the right sort
of inputs for what we need here. (It also doesn't seem to consider
the case of a baserel with a unique index for some reason...)

...Robert

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2009-02-18 21:28:55 Re: [COMMITTERS] pgsql: Start background writer during archive recovery.
Previous Message Tom Lane 2009-02-18 20:43:18 Re: [COMMITTERS] pgsql: Start background writer during archive recovery.