Re: Limiting the number of parameterized indexpaths created

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
>
> In the given example, the indexed relation "foo" has join clauses with
> 30 other relations. The code that I added in commit
> 3b8968f25232ad09001bf35ab4cc59f5a501193e will try all 2^30 combinations
> of those rels as possible outer relations for a parameterized indexscan
> :-(. So clearly, the idea that we can just try everything and not have
> some kind of heuristic restriction isn't going to work.

You know, when I read this, my first thought was ... why is this an
exponential relationship instead of a linear one? Even now, I'm not
sure I quite understand that. With a parameterized path, we get an
index scan (or index-only scan) with a.id taking its value from some
outer scan, but it can't take its value from more than one outer scan.
Can it? So what does it mean to parameterize the scan of foo by both
ag1 (aid) and ag2 (aid)?

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