Re: Limiting the number of parameterized indexpaths created

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Limiting the number of parameterized indexpaths created
Дата
Msg-id CA+Tgmoa-_yHnp1MBFGhqTj39F_a_55LE=KPjDR-cmWEFohZaZw@mail.gmail.com
обсуждение исходный текст
Ответ на Limiting the number of parameterized indexpaths created  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Limiting the number of parameterized indexpaths created  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: September 2012 commitfest
Следующее
От: Robert Haas
Дата:
Сообщение: Re: alter table tablename add column - breaks pl/pgsql function returns tablename