Re: Limiting the number of parameterized indexpaths created

On Mon, Nov 5, 2012 at 2:05 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Tue, Oct 30, 2012 at 5:57 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> I looked into the complaint of unreasonable planner runtime in bug #7626,
>>> http://archives.postgresql.org/pgsql-bugs/2012-10/msg00232.php
>
>> You know, when I read this, my first thought was ... why is this an
>> exponential relationship instead of a linear one?
>
> Because it's considering *combinations* of outer relations for a
> parameterized scan. For instance consider an index on t(a,b)
> and a query
> WHERE t.a = x.c1 AND t.b = y.c2
> There are three different parameterized paths we could create: one
> relying on x only, one relying on y only, one relying on both.

Sure, but that example is different from the test case provided in the
bug report. I agree that here we need to try paths parameterized by
a, b, or both a and b. Things might blow up multiplicatively, because
we have join clauses referencing both t.a and t.b. But they shouldn't
blow up exponentially, because each of t.a and t.b can only be
parameterized by ONE thing (I think). And in the example in the bug
report, only one column of the table (foo.id) is mentioned. foo.id
can be driven by ag1.aid OR ag2.aid OR ag3.aid OR ..., but not more
than one of those at a time.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company