Re: Limiting the number of parameterized indexpaths created - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Limiting the number of parameterized indexpaths created
Date
Msg-id CA+Tgmoa-_yHnp1MBFGhqTj39F_a_55LE=KPjDR-cmWEFohZaZw@mail.gmail.com
Whole thread Raw
In response to Limiting the number of parameterized indexpaths created  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Limiting the number of parameterized indexpaths created  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, Oct 30, 2012 at 5:57 PM, Tom Lane <tgl@sss.pgh.pa.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
scanof foo by both
 
ag1 (aid) and ag2 (aid)?

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



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: September 2012 commitfest
Next
From: Robert Haas
Date:
Subject: Re: alter table tablename add column - breaks pl/pgsql function returns tablename